[NUT-devel] Codec id - random notes

Michael Niedermayer michaelni at gmx.at
Tue Jun 27 18:34:05 CEST 2006


Hi

On Sat, Jun 24, 2006 at 01:27:24PM +0200, Michael Niedermayer wrote:
[...]
> in principle iam fine with any id system as long as its realistic
> (=people proposing complex stuff for nut must demonstrate the
> feasability of it first by implementing it)
> i also dont really care about being able to store broken mp4 in nut
> but i wont agree to a system being accepted based on a lie that it will
> work with every stream ...
> 
> so IMHO a id system must be able to achive the following, if it doesnt
> then IMHO its not worth considering
> 1. streamcopy (without decoder) every valid non broken stream from avi,mov,ogg
>    to nut and produce a valid and playable file

of course the avi case needs pts=dts to be valid to begin with


> 2. streamcopy every such file back to its source container and still have
>    a valid and playable file

if we want XXX->NUT->XXX to work with preserving the id then we could either

A:  allow any id to be used, so files converted from avi would contain
    a avi-4cc and from mov would have a mov-4cc
I:  make our own independant system which contains an id for every id in every
    other container (this could of course be done in 2 fields like format and
    implementation)
IA: store our own id and a source format id if available
AA: store as many ids as the muxer can map the input to (AVI-4cc and MOV-4cc...
IAA:store as many ids as the muxer can map the input to (AVI-4cc and MOV-4cc 
    and require a nut-id)
AAA:store as many ids as the muxer can map the input to (AVI-4cc and MOV-4cc 
    and require a AVI-4cc)


if we dont care about XXX->NUT->XXX
a: adopt a single existing id system like the one from avi or mov
b: like a but remap a few ids we dont like due to philosophical reasons
i: design our own indepenant system for per format ids (no implemtation id)


                                A   I   IA  AA  IAA a-avi   a-mov   b   i   AAA
supports old divx/xvid streams: X   X   X   X   X   X                       X
AVI->NUT->AVI wont change 4cc:  X   X   X   X   X   X                       X
MOV->NUT->MOV wont change 4cc:  X   X   X   X   X           X               X
no table maintaince:            X           X       X       X       x       X
decoder can use existing tables:X       X   X   x   X       X               X
decoder needs single nut-table:     X   X       X   X       X       X   X   X
encoder doesnt need to remap id:X           X                       x


so, nothing is perfect, we cant have everything ...

here are a few personal comments
AA vs. A
    both muxer and demuxer complexity are the same the only difference
    is that the muxer can store more ids if it knows them in AA, which
    might help the decoder if it doesnt know all id systems so IMHO we can
    drop A
IA vs IAA
    if we already support multiple ids per file then allowing to store
    more then 2 doesnt seem like a big differnce and might be slightly
    better in some cases, so id say drop IA
a-avi vs. a-mov
    there are more avi fourccs then mov fourccs so IMHO a-avi would be
    a better choice, theres also the old xvid/divx advantage, IIRC theres
    no distinction between the 2 in mov, so IMHO we can drop a-mov
b vs. a-avi
    b is philsophical better at the cost of playability of a very small number
    of divx & xvid videos and it needs a little more maintainance so IMHO
    we can drop b in favor of a-avi
i vs I
    if we are really building our own format id table then i guess a field
    more for the implemenattion wont hurt so IMHO drop i
AA vs. AAA
    AA has a big problem, the nut file could use any id system, so this
    moves alot of complexity to the demuxer, so i belive its not 
    controversical if i drop it in favor of some other system like AAA
    or another one which does the remaping at the muxer side

whats left:
                                I   AAA IAA a-avi
supports old divx/xvid streams: X   X   X   X
AVI->NUT->AVI wont change 4cc:  X   X   X   X
MOV->NUT->MOV wont change 4cc:  X   X   X
no table maintaince:                X       X
decoder can use existing tables:    X   x   X
decoder only needs single table:X   X   X   X
encoder doesnt need to remap id:


alternative suggestions, and comments welcome, personally iam fine with
all the options left (for I and IAA a volunteer would be needed to maintain
a few tables)

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



More information about the NUT-devel mailing list