[vorbis-dev] RFC draft for Vorbis over RTP

[Gregory Maxwell]

> I think delivery in the RTP channel should be possible, but I don't
> understand how you intend to handle dropped header packets. RTP
> generally used unreliable transport, and the stream is of course
> not decodable without the info and setup headers.

There are a number of FEC codes available for free which should make the
transmission of headers via RTP more robust. (see
http://info.iet.unipi.it/~luigi/fec.html )

The headers should still be available on demand via a unicast mechnism
for 'late joiners' and those who still missed the FEC protected headers.
It would also be nice if clients had a way to cache headers so if they
late-joined later they'd likely have them.

If such mechnisms were in place the transmitter could decide to transmit
the headers inline or not.. A smart method might be to only transmit them
if they differ from the last file (or more agressively within some other
time window.. or perhaps never send them). If it is decided that 'less than
always' is acceptable, then there should be some mechnism for the server
to transmit "you're going to need header sig X if you don't have it, here
it is..." or "You're going to need header sig Y if you don't have it
better go get it" so clients have a chance to get it via unicast in
advance if it won't be in the RTP or get corrections if part of the
transmission was lost. Obviously if a client has failed to obtain the
headers for a new content there will be some gap in playback when the
headers change.  It wont always be possible to know well in advance that
the headers will change, so RTP transmission of the headers is important.

A possible method of transmitting headers via unicast would be with via
http with URL transmitted in SDP. The advantage of using HTTP would be
that existing scalablity mechnisms (such as squid cache hierarchys or
reverse proxys like Akamai) for HTTP could be used.

It would be advantagious if the HTTP server contained the FECed
representation of the codebooks, this way clients could obtain only the
lost poritions via http byte-range requests. (If only the raw headers were
stored clients would need to obtain the whole thing as the FEC likely
won't provide partial decode for something as small as the headers are).

<p><p><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.