Tor-Einar at Jarnbjo.de
Thu Sep 1 15:47:04 PDT 2005
Luca Barbato wrote:
> Your "client" is a simple receiver that should be perfectly happy with
> the current baseline discussed, isn't it?
> If I'm wrong please tell me your constraints.
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.
- 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
- 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.
- The "baseline" is not practiable for multicast transmissions.
- I doubt that IETF will approve an RFC for content over RTP depending
on reliable transport and with no multicast support.
More information about the xiph-rtp