2006/6/27, Michael Niedermayer <michaelni@gmx.at>:
Hi
On Tue, Jun 27, 2006 at 04:00:26PM -0400, Rich Felker wrote: [...]
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"?
yes
[...]
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.
well, as we still dont have volunteer for maintaining nut-id and no initial nut-id table either, I/IAA options are pretty dead anyway ivan do you volunteer to do the work? and can you make a table containing all 4cc of avi & mov with nice format & implementation names?
No problem. That's easy. I hope you don't want it with past date. It needs few hours work. Of course I'll do it only if the format_id is really going to be used. I'd like discusion to be based on arguments and reasoning, not what Dick likes and what not.