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