[xiph-rtp] Codebook transmission

[Ralph Giles]

On Tue, Aug 30, 2005 at 08:50:50AM -0700, Aaron Colwell wrote:

> > Aaron and I also talked quite a bit about codebook transmission today.

Thanks for the corrections. Sorry I mangled the SDP stuff.

> I just want to clarify this a little. What I'm proposing is to have the
> ident header hex encoded in the fmtp field in the SDP. This roughly mirrors
> how the ESDS is transmitted for MPEG4.

Ah, and *not* broken out? I assumed there were standard keys for things
like frame size and sample rate that generic applicaions would want to
see.

> > For the single-forward channel (broadcast) application, they just have
> > to be baked in, or use some other transmission mechanism outside the
> > scope of our spec. Without the chain ID, you can't switch among defined 
> > codebooks though, unless you rely on inline transmission.
> > 
> > For IP unicast, we talked about http download. Something over RTSP would 
> > presumedly also work. So you'd have:
> > 
> >   a:fmtp codebook-url=http://example.com/streamheader.ogg
> 
> This doesn't quite follow SDP syntax. Here is an example of what I was
> suggesting.
> 
> a=fmtp:96 ident=4235AB45FAD4ABD6;codebook-url="http://example.com/streamheader.ogg"
> 
> The 96 is the payload type used in the a=rtpmap and m= lines. I put quotes
> around the url because ';' is a delimiter for the fmtp line, but is also a
> valid URL character.
> 
> > 
> > in the SDP. (and a similar v:fmtp for theora)
> 
> I think I confused Ralph on IRC with my SDP example. The Theora line should
> have the same format as the Vorbis one. There isn't a need to differentiate the
> two.
> 
> > 
> > Would 'header-url' be a better name?
> 
> If the URL only points to the codebook then I think codebook-url is good. If
> we are also going to have the ident and comment headers then I think header-url
> is probably better.
> 
> > Including a hash in the SDP to allow players to cache the
> > actual setup data still seems like a good idea. perhaps an extra
> > parameter thus:
> > 
> > v:fmtp codebook-url=http://example.com/stream/rtp8343.header \
> > ;header-md5=5d35bb7210c0a699d28aaf9baf7bb2e0
> 
> Here is an example with in the proper fmtp form.
> 
> a=fmtp:96 ident=4235AB45FAD4ABD6;codebook-url="http://example.com/stream/rtp8343.header";header-md5=5d35bb7210c0a699d28aaf9baf7bb2e0
> 
> > 
> > which the server MAY supply, with a MUST for what it's actually
> > a hash of.
> 
> If the ident is sent in the SDP I think we could say that the MD5 is always for
> the codebook only.
> 
> > 
> > Finally, Aaron suggested we let the RTP timestamp override the
> > fixed fps from the theora header/SDP, making a true variable
> > bitrate stream. This came up in the context of bitrate scalability
> > but also addresses the resampling cost when cutting between 
> > film and video, for example.
> > 
> > This has another advantage in that detecting dropped frames from
> > the sequence number can be difficult with fragemented packets, so
> > relying on the timestamp makes sense. It then become a question
> > of whether the timestamps have to match the fixed framerate from
> > the header. If not, however, there's no longer a one-to-one 
> > correspondence with an Ogg stream.
> 
> You could still generate a single Ogg stream. It would just have a much higher
> frame rate and you'd have to add a bunch of extra "empty" frames to fill in
> the gaps. :)
> 
> > 
> > We could make this dependent on the fps being undefined (0 or */0)
> > in the header.
> 
> The file still needs to have some frame rate information otherwise the server
> doesn't know how to timestamp the data or set the RTP session sample rate. On 
> the client side it doesn't need to look at the frame rate field in the ident
> header.

I was suggesting that if we intend the encoder to be able to optionally 
mess with the frame rate, it should signal that it will do so by setting
the fps in the ident header to 0 or undefined in the RTP stream. A 
source Ogg Theora stream would of course still have to have a fixed
frame rate.

We can also make it not optional. I was just worrying about the decoder
knowing whether is should be validating/rounding timestamps or not.

I'd also point out that timestamps still occur only once per RTP packet,
which with packing may span multiple theora packets. Given the relative
sizes of internet MTU and theora packets it's not a huge problem in 
practice to just be one-to-one, but we should define what happens if
somebody doesn't do that. Is the decoder supposed to interpolate the
display times?

 -r