2006/7/16, Michael Niedermayer <michaelni@gmx.at>:
Hi
On Sat, Jul 15, 2006 at 11:02:52PM +0100, Måns Rullgård wrote:
michael <subversion@mplayerhq.hu> writes:
Author: michael Date: Sat Jul 15 23:49:47 2006 New Revision: 19110
Modified: trunk/DOCS/tech/nut.txt
Log: clarify "extradata" comments welcome! if anyone disagrees ill reverse this and we can disscuss it, i just thought there wont be any disagreement and was too lazy to send a patch ...
Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Sat Jul 15 23:49:47 2006 @@ -512,6 +512,19 @@
codec_specific_data private global data for a codec (could be huffman tables or ...) + if a codec has a global header it SHOULD be placed in here instead of + at the start of every keyframe + the exact format is specified in the codec spec + codecs which dont specify it in their spec are specified below + for ogg based codecs (vorbis, theora) the following format shall be used + number_of_headers_minus_1 u(8) + for(i=0; i<number_of_headers; i++){ + -1 u(8*(size[i]/255)) + size[i] % 255 u(8) + } + for(i=0; i<number_of_headers; i++) + header[i] + Note, this is the same format these codecs use in matroska
If I didn't already know how what that format looks like, I'd have a hard time deciphering that description.
I still have no idea what it should do. At least header[i] is not associated with any type. My guess b(size[i]) If I had decoded the above correctly, then 65536 bytes of header would have about 257 bytes of 0xFF.... It's not acceptable to have that thing in nut. We have our own much better vlc system.
feel free to write a less obfuscated one ...
Could we perhaps generalize that format to include all codecs with several chunks of extradata, not only ogg based codecs? I'm not aware of any others, but for all I know they might exist.
ok, but the following needs disscussion: A always choose ogg style lacing B always choose v + packet data (nut style) C use whatever matroska uses + one of the above for the cases not supported by matroska
I don't think there is place for discussion. Always use nut style.
and there are many codecs which have several chunks all the mpeg variants do, but they have startcodes so its a non issue h.264 does too but with, the startcode prefixes being optional, IMHO we should just require the startcode prefixes to be in there ... then there are some mov based codecs like qdm2 which maybe need several chunks, they currently simply copy a whole set of mov chunks blindly into extradata in ffmpeg, that of course is a terrible mess which someone should fix in ffmpeg ...
How about one of the following: num_headers v for(i=0;i<num_headers;i++){ header[i] vb } --- or --- for(i=0; show_v() != 0; i++){ header[i] vb } 0x00 (aka vb with size 0); --- or --- (inside the codec_specific_data.value) for(i=0; i+show_v() <= codec_specific_data.length; i+= show_v() ){ header[i] vb } #2 is sensitive to data corruption, #3 could interpret older header in wrong way. #1 changes the frozen bitstream (hope nobody looks ;) I'd say KISS and use #1.