[xiph-rtp] Chaining

[Tor-Einar Jarnbjo]

Luca Barbato wrote:

>There aren't any streamcast (webradio) client that are using rtp only,
>all I know use rtsp/rtp, if you have rtsp and rtcp you have plenty of
>way to have feedbacks from client and push data asyncronously and deal
>with the shortcomings.
>  
>
So you intend to require RTSP as the only possible way to setup the RTP 
stream? Using RTCP for client feedback is of course an option, but is 
not necessarily very easy to implement or integrate in existing RTP 
servers/clients.

>Why is supposed to not know? btw if is an unicast transmission it will
>just start streaming the codebooks and then the rest...
>  
>
I already explained this one. Using RTP, the server is pushing the 
codebook data and has to know or assume the available bandwidth 
available to the client. If it sends the codebook packets too fast, they 
will be lost, if it sends them too slow, the startup delay will be 
higher than strictly necessary. If codebook packets are lost and the 
client must wait for a retransmission of parts of the codebook, it might 
not have memory to buffer enough audio to play the audio stream from the 
beginning.

>> The server does not know when to start audio streaming
>  
>
>And should not be a server concern, the client would have to skip till
>it can get them, check the mpeg4 case for a similar situation.
>The only problem is the retransmission frequency.
>  
>
I don't have time now to check any MPEG specification, but I think it 
should be obvious that it is not acceptable that it is likely that 
several seconds of the audio streamed must be skipped.

>to put some random values, you have 100packets in 2seconds, you chose to
>have something like 5 retransmissions (one each 20packets). If you lose
>that many packets in any case you'd have to skip.
>  
>
Random or not random. If you choose to resend the codebook every 400ms, 
you will need >100kbps just for codebook retransmissions, assuming that 
the codebook is 5 kilobytes. To use realistic values: If your audio 
stream is 100kbps and you try to send as large RTP packets as possible 
(1000-1500 bytes) to minimise framing overhead, you will have merely 
8-12 RTP packets/second.

>It is, the scenario is quite simple: you join the group and you should
>have to wait till you can get the codebooks, and that time is again
>dependent on the retransmission frequency (worst case 1 period)
>  
>
Using random values, the period length may be acceptable. If we continue 
with the realistic values of 100kbps audio and a 5kB codebook header, it 
looks very different. We then have ~12000 bytes audio data per second 
and if we accept an additional 5% bandwidth for codebook retransmissions 
(which is IMHO still too much), it will take >8s to transmit the 
codebook, which is not acceptable. Decrease the audio bandwidth or 
increase the codebook size as you like and the delay before having a 
complete codebook will make the implementation completely useless.

>If you like to have an HTTP based offband solution, please prepare a
>separate I-D, if I have time I'd start an RTSP I-D proposal or I'll let
>other interested group come with something.
>  
>
Wasn't the HTTP delivery method already part of Phil's last draft (-05)?

Tor