codec_specific_data

Hi

each stream has one global header in nut, matroska and avi 
too have exactly one global header APIs like the ones from
mplayer 
and ffmpeg and directshow AFAIK are also designed based on a
single 
global header

but a very small number of codecs are designed so that they
have
several global headers but no standarized way (that i know
of) of
converting them to a single header, the "ogg
codecs" fall in this
category

several solutions exist:
1. store several headers at nut level
2. leave it unspecified
3. specify how these multi packet codecs should be stored be
it in nut.txt
   or in a seperate file

if we do specify how these codecs should be stored then we
can either
A. invent our own system (this is for all practical proposes
is identical
   to storing them at nut level)
B. borrow the system from another container format


leaving it unspecified will lead to a mess of different
systems used by
different muxers

storing them at nut level will need them to be converted to
a single
packet format during demuxing and to a multi packet format
during nut
muxing in most cases

borrowing another system and using that throughout an
application will
lead to the least converting around



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

On Mon, Jul 17, 2006 at 11:43:30PM +0200, Michael
Niedermayer wrote:
> Hi
> 
> each stream has one global header in nut, matroska and
avi 
> too have exactly one global header APIs like the ones
from mplayer 
> and ffmpeg and directshow AFAIK are also designed based
on a single 
> global header

call the above text (*)...

> but a very small number of codecs are designed so that
they have
> several global headers but no standarized way (that i
know of) of
> converting them to a single header, the "ogg
codecs" fall in this
> category
> 
> several solutions exist:
> 1. store several headers at nut level
> 2. leave it unspecified
> 3. specify how these multi packet codecs should be
stored be it in nut.txt
>    or in a seperate file
> 
> if we do specify how these codecs should be stored then
we can either
> A. invent our own system (this is for all practical
proposes is identical
>    to storing them at nut level)
> B. borrow the system from another container format
> 
> 
> leaving it unspecified will lead to a mess of different
systems used by
> different muxers

agree, this is not an option.

> storing them at nut level will need them to be
converted to a single
> packet format during demuxing and to a multi packet
format during nut
> muxing in most cases

due to (*), all this does it create a huge deal of
complexity at the
muxer level for the sake of a few broken codecs. better to
identify
them as broken and provide supplemental specs for how to
pack the
extradata. this is what was discussed before, anyway.

i've said it many times before, my fundamental law of hacks
and
workarounds is that whenever you're integrating a broken
component (in
this case the strange codecs) into an otherwise clean
system, you
always isolate the hacks to support the broken component as
close as
possible to the broken component.

> borrowing another system and using that throughout an
application will
> lead to the least converting around

and it will also encourage the adoption of standards that
will
facilitate storing these broken codecs in any container, as
opposed to
just solving the problem for nut alone. haali seems willing
to work
with us on this, and having his support would be great for
getting nut
into widespread use.

rich

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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

Rich Felker wrote:
> and it will also encourage the adoption of standards
that will
> facilitate storing these broken codecs in any
container, as opposed to
> just solving the problem for nut alone. haali seems
willing to work
> with us on this, and having his support would be great
for getting nut
> into widespread use.
> 

while we are at it, I'd strip the comment packet completely
from vorbis
and theora and expect the application to provide a dummy one
if the
decode desperately wants one.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/
~lu_zero

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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

On Tue, Jul 18, 2006 at 03:57:37AM +0200, Luca Barbato
wrote:
> Rich Felker wrote:
> > and it will also encourage the adoption of
standards that will
> > facilitate storing these broken codecs in any
container, as opposed to
> > just solving the problem for nut alone. haali
seems willing to work
> > with us on this, and having his support would be
great for getting nut
> > into widespread use.
> > 
> 
> while we are at it, I'd strip the comment packet
completely from vorbis
> and theora and expect the application to provide a
dummy one if the
> decode desperately wants one.

the "standard" format is already specified, and
moreover, the comment
might even be used to store version information that the
decoder would
use to recover from buggy encoders.

however, it would be nice to add a clause in the vorbis
header packing
spec indicating that players should ignore any metadata from
the
vorbis comment packet.

rich


_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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