[NUT-devel] Codec id - random notes

[Ivan Kalvachev]

2006/6/27, Michael Niedermayer <michaelni at gmx.at>:
> 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)

Excellent analysis. I guess there is no need to say I am in favour of
IAA system.

We need compatibility (so 'I' is out)

I demand creating our own system. The purpose - once the other formats
are obsolete this system will be the only valid. (this eliminates
i-avi and AAA).

I had proposed 'I' type system in my "Fourcc vs format_id" mail.
In short:
"format_id" - string with the format specific stream. Must not overlap
with any of the existing systems. No acronyms.
"profile" - used capabilities of the profile. (hw players quick
rejection, stream servers support).
"encoder" string describing the encoder&version(used for bugs
workaround and fame/blame of quality).