[vorbis-dev] RFC draft for Vorbis over RTP

[Tor-Einar Jarnbjo]

Gregory Maxwell wrote:

>Correct. I would also suggest that the headers be encoded with forward
>error correction.. a modest increase in their size will translate into a
>substantial increase in resistance to packet loss.
>
>  
>
Anyone else with an opinion on this? If using FEC on the codebooks,  we 
could also just as well consider it an option for the media packets. I 
don't know if it would be possible to implement some sort of graceful 
packet loss compensation in the Vorbis decoder, but as it is, packet 
loss might have a higher impact on Vorbis than on other codecs, as the 
Vorbis decoder needs the previous packet to decode properly (one packet 
lost will cause two packets missing in the PCM output). At least for the 
RTP packets, it would even be possible to use a separate stream for the 
extra FEC data (also in a multicast environment), allowing the client to 
decide itself if  it needs the error codes to compensate for packet loss.

>I also suggest that the protocol be setup to work correctly even if the
>headers are never transmitted in the stream (clients must always fetch) or
>if there is no out of band source (clients must wait until they get a copy
>via RTP, hopefully a server like this would send codebooks a little more
>often)..
>
I don't like the perodical retransmission of the header packets at all. 
The codebooks have a significant size and if these periodic 
retransmissions is the only way for the client to get the codebooks, 
they would either have to be retransmitted often (expecting the client 
to wait much longer than 5-10 seconds to start playing would be too much 
IMHO) and retransmitting a 16kB codebook set (this was mentioned 
somewhere as a typical size) every 10 seconds would increase the 
required bandwidth by 13kbps.

In my opinion, the following two ways to obtain the codebooks ought to 
be enough:

- For unicast streams, use a reliable OOB transport like HTTP

- For multicast streams, still allow (mandatory) a reliable OOB 
transport like HTTP and have an optional separate media stream, which is 
repeatedly transmitting the currently active codebook. This would allow 
the client to join the multicast stream if codebook retrieval is 
necessary and stop receiving the codebook stream as soon as enough data 
is available to reconstruct and parse the codebooks. Securing this 
stream with FEC would of course still make sense.

> Also, it should be possible to form a codebook transmission
>packet in the RTP stream that gives a codebook hash, but has no data (this
>is a marker for clients to go get the codebook via the OOB method, so they
>can go get it before it's needed).. It should also be possible to mark
>those codebook transmission packets with a flag "don't use cached copy" so
>that clients will accept the transmitted codebook or fetch one even if
>they have a cached copy. 
>
>--- >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.
>
>  
>

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