[NUT-devel] Codec id - random notes

[Rich Felker]

On Tue, Jun 27, 2006 at 06:34:05PM +0200, Michael Niedermayer wrote:
> 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

Maybe so, but this is false for 99% of relevant avi files.

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

This is fine with me except for the twocc audio crap which is
questionable...

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

Ugly, redundant, bloated.

> 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

I don't care about it. Do others?

> 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

To me, the critical ones are:
- no table maintaince
- using existing tables or existing tables with a few minor additions

IMO "encoder doesnt need to remap id" is odd, maybe this means
"remuxer from other format doesn't need to remap id"?

> 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

I agree with your reasoning here.

> 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

If the avi-style fourcc is required, it seems a bit odd to have other
format ids too. Any demuxer implementation will have to be able to
read the avi fourcc (in case it's the only one there), so what's the
good of having more ids?

The only way I find the AAA option interesting is if we require one of
the ids to refer to a bitstream standard (instead of implementation)
whenever the stream is standards-conformant. This would allow players
that don't support proprietary codecs and don't want to deal with all
the fourcc mess of those to play files without a table of all the
implementation ids, and would allow players to play files encoded with
new implementations (of mpeg4, etc.) without upgrading their tables.

(SHOULD instead of MUST would also be acceptable here, with the
implication that users may have to upgrade their players unnecessarily
to play files ignoring the recommendation.)

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

I generally dislike anything involving nut-id. It's just like
matroska, useless bloat.

Otherwise I'm mostly ok with AAA or a-avi. Perhaps with the above
addition to AAA.

Rich