[vorbis-dev] RFC draft for Vorbis over RTP

[Tor-Einar Jarnbjo]

Aaron Colwell wrote:

>I was planning on retransmitting the headers periodically. In the case of 
>an unicast delivery the client could ACK the headers via an RTCP APP packet.
>This would tell the server to stop sending the headers for that chain. Even 
>if the ACK gets dropped the client will send another one when it gets a header
>it already has. In low loss conditions, only one ACK will be needed.
>
This sounds to me like a potential relevant waste of bandwidth. I 
suppose a typical codebook would be split into so many RTP packets, that 
a transmission failure is rather likely, even with a typically low 
packet loss. It is also possible, that future encoders may use a more 
complex (larger) codebook lists to obtain better compression of the 
actual audio data, making this situation even worse.

I also don't like the idea about having a codebook URL in the SDP 
descriptor. Would such a solution allow a midstream change of the 
codebooks at all, or wouldn't this lock the entire stream to one set of 
codebooks?

I have been thinking a bit about a combination of these two concepts, 
which hopefully may solve some of the problems (especially bandwidth 
usage) and make the delivery more robust:

- As Aaron already wrote, each RTP packet must contain an id of the 
codebooks used to encode it. As I can see, this is the only way to 
ensure that a packet is decoded using the correct codebook.

- Some time before a codebook switch, the server will start sending RTCP 
packets informing the client about this and the new codebook id. These 
packets will typically be only a few bytes and I don't see it as a huge 
drawback if the server periodically repeats the same packet for some 
time. The packets should also include a field defining the time (e.g. 
number of seconds) until the codebook change will become active and the 
codebook size. This allows the client a better bandwidth management in 
cases where the main RTP stream consumes a large part of the available 
bandwidth. E.g. the client is playing a 48kbps stream over a 64kbps 
line. In this case, starting a normal, bandwidth unrestricted HTTP 
download will probably break the RTP stream. If the client however 
knows, that it yet has 30 seconds to download a 15 kB codebook, the 
client could throttle the HTTP download, preventing the RTP stream to break.

- There is an SDP header field for the codebook URL and there is a 
placeholder defined for the codebook id (and if it turns out necessary 
later, even other relevant attributes). If the URL is defined as 
http://foo.com/cgi-bin/codebook?id={cbid} and the client is notified, 
that a codebook with id 4711 will become active, the client would 
request the codebook from http://foo.com/cgi-bin/codebook?id=4711. 
Gregory already mentioned the advantage of proxying the HTTP requests, 
but also regular HTTP caching mechanisms would save bandwidth. Low 
bandwidth broadcasts (e.g. targeted for mobile clients) may choose to 
use the same codebooks over a longer period of time. A rejoining client 
could then even after several days with a small GET requests with an 
If-Modified-Since header be determined that it can keep using the 
codebooks it still has from the last session.

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.