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

[Ivan Kalvachev]

2006/7/16, Michael Niedermayer <michaelni at gmx.at>:
> Hi
>
> On Sat, Jul 15, 2006 at 11:02:52PM +0100, Måns Rullgård wrote:
> > michael <subversion at 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.