Ralph Giles
2005-08-29 17:59:06 UTC
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.
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
in the SDP. (and a similar v:fmtp for theora)
Would 'header-url' be a better name?
There are two proposals for the header format itself. One is to use Ogg,
just making available the headers as if it were a normal stream. I don't
think this is onerous. Most players will be linked with libogg anyway to
also handle http streaming, and if not, a non-validating Ogg parser can
return the headers in a page or so of code.
A caveat here: the idea is this is braindead simple if you're
already serving from an Ogg stream, and not hard to construct if
you're not.
However, in the case of a multiplexed Ogg stream, the server may
have to split things out to make the right header set the one the
decoder finds. So we can either always require this, by specifying
the url MUST return a degenerate Ogg stream with the matching
headers and only the matching headers at the start, or we can use
an additional parameter like 'header-index=4' to tell the decoder
to use the fourth logical bitstream it finds. I don't like this
second option on elegance grounds, but being able to use the same
url for both vorbis and theora headers in an A/V stream is an
advantage.
The other proposal is Luca's with just a sequence of 4-byte length,
packet data pairs. This is much simpler to generate and parse, but
if we do this, we really need to define a MIME type under which it
can be served. application/x-vorbis-headers? video/x-theora-headers?
We need to decide if we want to support either of these formats or
both.
For multicast, the 'all headers, all the time' stream still works
fine, using the same RTP payload as the data stream. Aaron's suggestion
was just to have the codebook-url point to an SDP for the header
multicast stream.
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
which the server MAY supply, with a MUST for what it's actually
a hash of.
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.
We could make this dependent on the fps being undefined (0 or */0)
in the header.
-r
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.
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
in the SDP. (and a similar v:fmtp for theora)
Would 'header-url' be a better name?
There are two proposals for the header format itself. One is to use Ogg,
just making available the headers as if it were a normal stream. I don't
think this is onerous. Most players will be linked with libogg anyway to
also handle http streaming, and if not, a non-validating Ogg parser can
return the headers in a page or so of code.
A caveat here: the idea is this is braindead simple if you're
already serving from an Ogg stream, and not hard to construct if
you're not.
However, in the case of a multiplexed Ogg stream, the server may
have to split things out to make the right header set the one the
decoder finds. So we can either always require this, by specifying
the url MUST return a degenerate Ogg stream with the matching
headers and only the matching headers at the start, or we can use
an additional parameter like 'header-index=4' to tell the decoder
to use the fourth logical bitstream it finds. I don't like this
second option on elegance grounds, but being able to use the same
url for both vorbis and theora headers in an A/V stream is an
advantage.
The other proposal is Luca's with just a sequence of 4-byte length,
packet data pairs. This is much simpler to generate and parse, but
if we do this, we really need to define a MIME type under which it
can be served. application/x-vorbis-headers? video/x-theora-headers?
We need to decide if we want to support either of these formats or
both.
For multicast, the 'all headers, all the time' stream still works
fine, using the same RTP payload as the data stream. Aaron's suggestion
was just to have the codebook-url point to an SDP for the header
multicast stream.
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
which the server MAY supply, with a MUST for what it's actually
a hash of.
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.
We could make this dependent on the fps being undefined (0 or */0)
in the header.
-r