On Sun, Jul 16, 2006 at 02:58:02AM +0200, Michael Niedermayer wrote:
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
Keep in mind that the _intent_ of specifying this is _NOT_ that the NUT muxer or demuxer would have to process such mess, but rather that implementations should treat the specified extradata format as the standard for the codec, and put whatever hacks are necessary to use legacy implementations (e.g. libvorbis) in the wrapper code for the library.
and there are many codecs which have several chunks all the mpeg variants do, but they have startcodes so its a non issue
Yes, for once sanity prevails..
h.264 does too but with, the startcode prefixes being optional, IMHO we should just require the startcode prefixes to be in there ...
Agree strongly!
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 ...
Any good ideas? If the mov atoms aren't hard to parse I wonder if original Qt codecs should just be allowed to keep their mov atoms... Of course this is unacceptable for any standard codec that just happens to be stored in mov, including mpeg4/h264. Rich