[xiph-rtp] Lots of proposals

Tor-Einar Jarnbjo Tor-Einar at Jarnbjo.de
Tue Sep 6 15:38:05 PDT 2005


David Barrett wrote:

> You've proposed sending codebooks at the stream rate -- a safe, 
> reasonable, but very slow solution.  There are other choices that are 
> still safe but much faster, especially with acknowledgement.  Indeed, 
> if you choose not to play nicely with other TCP streams, you can even 
> go *faster* than TCP using UDP (and for realtime data as small as 5KB, 
> this might be a fine choice).

Not if you are concerned about implementation effort. Of course you can 
reimplement parts of the already available TCP stack to achieve reliable 
stream transfers over UDP, but that would have to include ack or resend 
messages from the client and some sort of bandwidth usage control. 
Without a two way communication, the server will never know for sure 
that the codebook has been completely received by the client, so that it 
can start streaming the audio content.

> Anyway, this is the real reason I'm responding.  One assumption I hold 
> that's biasing all of my discussion is "whatever decisions are made 
> for Vorbis-rtp will likely be applied to Theora-rtp".  Can anyone 
> confirm or deny that this is the case?
>
> Personally, I think Vorbis and Theora (even Speex -- it doesn't send 
> codebooks, but it does have stream parameters that must be delivered 
> reliably) are so similar in this respect that we'd be silly not to use 
> the same approach for all.  Do you have an opinion on this?

I do not have any detailed knowledge about Theroa, but I don't see any 
similarities between Vorbis, Speex and FLAC justifying the effort to try 
to find a common RTP solution for them. Speex was designed for 
unreliable transports to begin with and has AFAIK completely 
self-contained packets, e.g. a single packet can be decoded properly 
without any other knowledge about the stream. FLAC only has a very small 
mandatory setup header, which can easily be transfered as SDP 
parameters. On the other side, FLAC over RTP would e.g. have to cope 
without seek-points as they don't make any sense in a streaming situation.

> - Agree on a fixed set of codebooks for RTP.  ...
>
> I actually agree with you here, but it's my impression that this 
> widely-discussed option has been formally rejected by Xiph.

I'm not sure and the mailing list archive is too difficult to search for 
me to bother. I'm wondering why we're not hearing anything from then or 
from Fluendo in this discussion.

Tor



More information about the xiph-rtp mailing list