[NUT-devel] Fourcc spec

[Michael Niedermayer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20061222/aa3ce87a/attachment.pgp>