[xiph-rtp] Codebook transmission

[Aaron Colwell]

On Mon, Aug 29, 2005 at 12:59:05PM -0700, Ralph Giles wrote:
> Aaron and I also talked quite a bit about codebook transmission today.
> 
> A quick summary:
> 
> Things are simplified my having only one set to transmit.
> 
> First, the decoder MUST handle headers sent inline in the RTP stream.
> 
> Aaron also suggested that all the info header parameters (sample rate,
> frame size, number of channels and so on) be mirrored in the SDP as 
> well. Sounds good to me.

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.

> 
> 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. It can just look at the sample rate of the RTP session. If it was 
writing data out to a file. It could just change the frame rate in the ident
header to 1 / (RTP sample rate) and then generate "empty frames" for the gaps.
Obviously you might want to add some smarts to figure out what the frame rate
is so that you don't waste a bunch of space on empty frames.

Aaron

> 
>  -r
> 
> _______________________________________________
> xiph-rtp mailing list
> xiph-rtp at xiph.org
> http://lists.xiph.org/mailman/listinfo/xiph-rtp
>