header packing for xiph codecs
At some point we talked about there being a general need to pack the necessary decoder initialization headers for codecs like Vorbis and Theora into a single binary blob, and how it would be nice if there were some standard way to do that. I've been pushing for something like that in the RTP payload specs, which are going through a new round. So, what do you think of the following: - 24 bit "unique id" marking the header for reference - number of headers, encoded as a variable-length unsigned integer, using the 'v' method from the nut spec - for each header: * length of the header in bytes, encoded using the 'v' method * header data, padded out to the nearest byte boundary Comments please, -r
Hi On Mon, May 07, 2007 at 03:22:17PM -0700, Ralph Giles wrote:
At some point we talked about there being a general need to pack the necessary decoder initialization headers for codecs like Vorbis and Theora into a single binary blob, and how it would be nice if there were some standard way to do that.
I've been pushing for something like that in the RTP payload specs, which are going through a new round. So, what do you think of the following:
- 24 bit "unique id" marking the header for reference - number of headers, encoded as a variable-length unsigned integer, using the 'v' method from the nut spec
- for each header: * length of the header in bytes, encoded using the 'v' method * header data, padded out to the nearest byte boundary
Comments please,
well any standardized packing is a big improvement for everyone who has to deal with xiph codecs in situations where multiple global packets are not possible ... your specific suggestion above seems like a fairly simple and flexible choice one thing though which id like to say (again) is that the global headers generally contain only data essential for decoding the stream. and because of that things like RTP and containers might try very hard to keep them intact possibly at the expense of startup delay and file size ... so putting comments, description and other metadata in them is IMO a very bad idea ... PS: as a quite off topic note, IMO RTP should be more generic and not require a new RFC for every codec (this is shitty design IMHO) if it where just for things like the header packing that would be understandable, but looking at for example the 200kb of text needed to describe h.264-rtp i feel the urge to vomit, 200kb should be enough to describe a RTP like protocol which supports all current and future mpeg and h.26x codecs and propriatery variants [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato
On Tue, May 08, 2007 at 02:59:02AM +0200, Michael Niedermayer wrote:
one thing though which id like to say (again) is that the global headers generally contain only data essential for decoding the stream. and because of that things like RTP and containers might try very hard to keep them intact possibly at the expense of startup delay and file size ... so putting comments, description and other metadata in them is IMO a very bad idea ...
Sure. In particular, the rtp draft has a mechanism for transmitting metadata updates separately, and currently says an encoder may want to strip the metadata. I was just trying to make it simple and consistent, so you can pass everything if you want, and not have to think too hard about it. Anyone else I should run this by? I guess matroska have already done a format (similar, but using Ogg-style lacing for the length fields) so I guess it's too late for them. Anyone else working on containers?
PS: as a quite off topic note, IMO RTP should be more generic and not require a new RFC for every codec (this is shitty design IMHO)
It's even worse than Ogg! :^) -r
Michael Niedermayer wrote:
PS: as a quite off topic note, IMO RTP should be more generic and not require a new RFC for every codec (this is shitty design IMHO)
I'm trying to make at least vorbis and theora consistent and pretty much the same beside what you store in the sdp (video vs audio info), hopefully dirac would fit into the framework too.
if it where just for things like the header packing that would be understandable, but looking at for example the 200kb of text needed to describe h.264-rtp i feel the urge to vomit, 200kb should be enough to describe a RTP like protocol which supports all current and future mpeg and h.26x codecs and propriatery variants
h264 it the easiest rtp packetizer I read since mpegaudio, go figure... lu - mpeg4 is the real joy... -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
participants (3)
-
Luca Barbato -
Michael Niedermayer -
Ralph Giles