[vorbis-dev] RFC draft for Vorbis over RTP

[Aaron Colwell]

On Thu, May 27, 2004 at 12:19:20AM +0200, Tor-Einar Jarnbjo wrote:
> 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.

It might be a good idea to see how Vorbis fairs on it's own before adding FEC.
We can always add RFC 2733 support or some other FEC later if needed.

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

You make valid points. I am curious whether any other RTP payload format
has needed to transport data reliably. We should probably see how others
have solved the problem in the past. 

I only suggested periodic retransmission because it didn't require anything 
other than a standard RTP stack to implement. I also figured that in most 
cases the packets would not get dropped and so the codebooks would only be 
transmitted once anyways.

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

Here are my concerns with the HTTP solution.
- How are the codebooks stored on the server? Are they just in their own
  file?

- How does the streaming server know what codebook URL is associated with
  each ogg file? This association must be kept up to date at all times or else
  it will cause problems. This constitutes an server administration burden.

- Except for your multicast scenario, this mechanism requires an HTTP stack 
  as well as an RTP stack. This is a greater burden than most RTP payloads that
  I am aware of. This may not be that big of a deal, but it is something to
  consider.

One solution that could help the codebook administration problem that I 
mentioned is to specify an offset and size with the URL. Then the URL can just
be an HTTP url to the source file and the offset and size can allow you to grab
the codebook chunk right out of it assuming you are using HTTP 1.1. The 
streaming server will likely know where the codebook is in the file so you 
don't have to worry about keeping the codebook and ogg file in sync with 
eachother. For live streams you can just put the codebook in a file and use 
a 0 offset.

I'll think about the HTTP solution a little more and see if I can think of any
other problems or benefits of this solution.

Aaron

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