r19110 - trunk/DOCS/tech/nut.txt

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
 
 frame_code
     the meaning of this byte is stored in the main header
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

michael <subversionmplayerhq.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.

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.

-- 
Måns Rullgård
mruinprovide.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Hi

On Sat, Jul 15, 2006 at 11:02:52PM +0100, Måns Rullgård
wrote:
> michael <subversionmplayerhq.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.

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

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 ...

[...]
-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or
copy any book
Today you'd get arrested for mere telling someone where the
library is
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

2006/7/16, Michael Niedermayer <michaelnigmx.at>:
> Hi
>
> On Sat, Jul 15, 2006 at 11:02:52PM +0100, Måns Rullgård
wrote:
> > michael <subversionmplayerhq.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.
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Michael Niedermayer <michaelnigmx.at> writes:

> and there are many codecs which have several chunks
> all the mpeg variants do, but they have startcodes so
its a non issue

Hmm... I've never heard of MPEG1/2 stored with OOB data. 
Have I been
looking in the wrong places?

> h.264 does too but with, the startcode prefixes being
optional, IMHO we 
> should just require the startcode prefixes to be in
there ...

Makes sense.

> 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 ...

Whoever designs codecs like that should be shot.

-- 
Måns Rullgård
mruinprovide.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Hi

On Sun, Jul 16, 2006 at 02:04:48PM +0100, Måns Rullgård
wrote:
> Michael Niedermayer <michaelnigmx.at> writes:
> 
> > and there are many codecs which have several
chunks
> > all the mpeg variants do, but they have startcodes
so its a non issue
> 
> Hmm... I've never heard of MPEG1/2 stored with OOB
data.  Have I been
> looking in the wrong places?

no, ive never heard of it either ...

[...]
-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or
copy any book
Today you'd get arrested for mere telling someone where the
library is
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Michael Niedermayer <michaelnigmx.at> writes:

> Hi
>
> On Sun, Jul 16, 2006 at 02:04:48PM +0100, Måns Rullgård
wrote:
>> Michael Niedermayer <michaelnigmx.at> writes:
>> 
>> > and there are many codecs which have several
chunks
>> > all the mpeg variants do, but they have
startcodes so its a non issue
>> 
>> Hmm... I've never heard of MPEG1/2 stored with OOB
data.  Have I been
>> looking in the wrong places?
>
> no, ive never heard of it either ...

So I should just ignore what you said?

-- 
Måns Rullgård
mruinprovide.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Hi

On Sun, Jul 16, 2006 at 03:15:50PM +0100, Måns Rullgård
wrote:
> Michael Niedermayer <michaelnigmx.at> writes:
> 
> > Hi
> >
> > On Sun, Jul 16, 2006 at 02:04:48PM +0100, Måns
Rullgård wrote:
> >> Michael Niedermayer <michaelnigmx.at> writes:
> >> 
> >> > and there are many codecs which have
several chunks
> >> > all the mpeg variants do, but they have
startcodes so its a non issue
> >> 
> >> Hmm... I've never heard of MPEG1/2 stored
with OOB data.  Have I been
> >> looking in the wrong places?
> >
> > no, ive never heard of it either ...
> 
> So I should just ignore what you said?

if you like ...

mpeg1/2 do have several chunks which could be considered to
be global
headers but noone stores them out of band / in a global
header furthermore
they could be trivially stored as they are in a global
header due to their
startcodes delimiting the individual chunks

[...]

-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or
copy any book
Today you'd get arrested for mere telling someone where the
library is
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Michael Niedermayer <michaelnigmx.at> writes:

> Hi
>
> On Sun, Jul 16, 2006 at 03:15:50PM +0100, Måns Rullgård
wrote:
>> Michael Niedermayer <michaelnigmx.at> writes:
>> 
>> > Hi
>> >
>> > On Sun, Jul 16, 2006 at 02:04:48PM +0100, Måns
Rullgård wrote:
>> >> Michael Niedermayer <michaelnigmx.at> writes:
>> >> 
>> >> > and there are many codecs which have
several chunks
>> >> > all the mpeg variants do, but they
have startcodes so its a non issue
>> >> 
>> >> Hmm... I've never heard of MPEG1/2 stored
with OOB data.  Have I been
>> >> looking in the wrong places?
>> >
>> > no, ive never heard of it either ...
>> 
>> So I should just ignore what you said?
>
> if you like ...
>
> mpeg1/2 do have several chunks which could be
considered to be global
> headers but noone stores them out of band / in a global
header furthermore
> they could be trivially stored as they are in a global
header due to their
> startcodes delimiting the individual chunks

I guess you're referring to the sequence header and related
extension
headers here.  Yes, those could be stored OOB, but the
standard
doesn't make any such provisions.

-- 
Måns Rullgård
mruinprovide.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Sat, Jul 15, 2006 at 11:49:47PM +0200, michael wrote:
> 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

I like this change, but storing them all in the main spec
file will
get out of hand if there come to me many more codecs that
require
stupid formatting. Maybe we could put stuff like this in a
supplemental file.

I was talking with Haali (of windows fame) on #ffmpeg and he
said
Matroska already has a list of extradata formats, packed
into a single
binary data block. I have not read it yet but here's the
file:
http://haali.cs
.msu.ru/mkv/codecs.pdf
We might want to consider making a sort of
"alliance" on this to
strengthen the notion that "single binary block in
header" is the
standard for codec init data, and that all containers and
codecs
should conform to it.

Rich

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel