[xiph-rtp] Chaining

[Luca Barbato]

Ops, I didn't replyall, resending to the list (that is slightly
modified, reread please)

First:

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.


Tor-Einar Jarnbjo wrote:


>> I already mentioned several in my responses to your and David Barrett's
>> mails on Monday and Tuesday, but I can of course summarize:
>> 
>> - The server does not know how fast it can stream the codebook. Limiting
>> the transmission speed to the audio stream bandwidth may cause an
>> inacceptable delay when starting playback and will in most cases cause a
>> longer delay than necessary compared to e.g. HTTP based retrieval.

Why is supposed to not know? btw if is an unicast transmission it will
just start streaming the codebooks and then the rest...

>> 
>> - The server does not know when to start audio streaming if it doesn't
>> get any feedback from the client that the codebook has been completely
>> received.

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.

>> 
>> - Repeating the codebook transmission at specific intervals to assure it
>> is received by the client may waste unavailable bandwidth and may
>> prevent the client from playing from the beginning of the audio stream
>> if it is not able to cache the audio streamed before the complete
>> codebook header is received.
>> 

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.

>> - The "baseline" is not practiable for multicast transmissions.

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)

>> 
>> - I doubt that IETF will approve an RFC for content over RTP depending
>> on reliable transport and with no multicast support.

The baseline solution uses JUST rtp, supports multicast the same way it
supports unicast and could not be as bad as we are all thinking.

If you have better ideas I'm always open to suggestions.

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.

lu


-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero