[NUT-devel] r19110 - trunk/DOCS/tech/nut.txt

[Rich Felker]

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