[vorbis-dev] RFC draft for Vorbis over RTP

[Gregory Maxwell]

On Thu, 27 May 2004, Tor-Einar Jarnbjo wrote:
> 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.
With most FEC implimentations the extra data isn't just 'extra'. Though I
suppose you could make one RTP include the bare minimum needed for
decode.. Really if you go totally gunho with FEC it would be advantagious
to break up the vorbis packets and transmits the differnt layers of the
cascade with differing amounts of FEC protection. This would be nice but
the standard is already too delated. This would cause packet loss to just
reduce the quality.  Making this work along with selective subsccribtion
would be a bit complex (my idea above of having one RTP stream with only
enough data to decode if there is no loss would not mix will with having
varried amounts of FEC on the packets)
> 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.
Sometimes the long delay might be acceptable (esp in the case were the
client caches headers and only one set of headers is ever used by the
station)...  Consider a DSL host serving to 10,000 multicast listners..
Perhaps the host has no scalable place to put the headers.. The option to
include them should be preserved.. esp as including them is a good
mechinism for distributing them to already connected clients in advance of
a switch to a concatinated stream.. The codebooks could be sent in small
packets and dribbled out over several seconds in advance of the change..
if the server thinks that most of the clients don't have them already...

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