Hi On Fri, Dec 22, 2006 at 12:56:26PM +0200, Oded Shimon wrote:
Hi Time to kick a dead horse.... Or set it on fire or something.
On Sat, Nov 18, 2006 at 01:43:33AM +0100, Michael Niedermayer wrote:
well, before all the idiocity from mans and co, we simply added a fourcc to riff.c (avidec or enc or whatever it was back then) and that format could be muxed and demuxed in avi and every other format using the riff table, my idea was that nut would use that and only that table, sure it was my idea and not yours or odeds, but all the table split madness leaves me already with a longer todo list, or more specifically i now need to go through all codecs in lavc and add fourccs to riff.c for the ones which can be stored in avi as everyone who touches the table gets flamed by either mans or baptiste and nut seems to be on the way to double that work, if its table is split off sufficiently
I absoloutely understand your argument of not wanting to split the fourcc table you have currently for AVI and other containers. However, I also understand Mans' argument of the NUT spec having absoloutely no specification of fourcc's/codec_id's. Unfortunatly, the only solution I see that pleases the both of you is the silliest one - having "DX50" and "\x55\x00" as official NUT fourcc's. - This is actually the current situation, it is simply not explicitly official.
What solution do you propose for this? Ignore Mans' argument altogether and leave the situation as it is? In a very simple example I saw where his argument was useful - in my framecode generator for libnut based on codecs. I would actually have to maintain complete lists to pick the codec instead of a simple single test.
The general NUT habit so far was to ignore existing implementation limitations...
its easy to find arguments against any solution, but unless you compare 2 possible solutions this is meaningless question is not if solution X has a flaw, question is which solution has the fewest flaws the only way to avoid a list of fourccs per codec in a framecode generator is to convert all mpeg4 like codecs to a single fourcc, and similarly for other standard codecs, this first will break bug workarounds for some rare and old files if libavcodec is used as decoder, it will cause xvid and divx to be played by the same decoder on windows, is xvid capable to decode all divx? is divx capable to decode all xvid? divx definitly doesnt decode standard mpeg4 correctly, there are plenty of bugs B before I and such IIRC additionally any solution which doesnt need a fourcc list in the framecode generator needs it in the demuxer-muxer so i dont see how that simplifies anything? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus