[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