[NUT-devel] Fourcc spec

[Oded Shimon]

On Sat, Nov 18, 2006 at 01:43:33AM +0100, Michael Niedermayer wrote:
> On Fri, Nov 17, 2006 at 01:36:59PM -0500, Rich Felker wrote:
> > On Fri, Nov 17, 2006 at 06:42:19PM +0100, Michael Niedermayer wrote:
> > > first look in the nut table if nothing is found look in the riff table
> > > for muxing, same for demuxing
> > 
> > IMO the best is probably for the user to manually select the fourcc
> > for NUT muxing when it's not one of the standardized codecs. But I
> > don't really mind if you prefer something different.
> > 
> > > this also breaks my idea of simply exporting fourcc-codec_id as an array
> > > in AVCodec, as for nut the thing suddenly would be 2 tables ...
> > 
> > ??? I don't follow. No one ever said muxing could be done with a
> > unified table. Still, a next-gen media app might support playing all
> > formats but writing only NUT, in which case a single table would be
> > fine. Obviously a library like libavformat will have to go through
> > some trouble to ensure that the correct/preferred codec_id for each
> > container is used... There's no way around this without dropping
> > support for legacy formats.
> 
> 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,

Personally I don't see this as a big issue. I already started making an 
(extremely minimal) table in lavf/libnut.c - and it should be a very easy 
table to maintain as it is defined by spec in fourcc.txt . It adds about 1 
or 2 lines of code in checking this table first before checking the riff 
table. I'd hate to join mans's side of the flaming ;) - But I fail to see 
the big advantage of using a single, large table in riff.c for several 
almost obviously incompatible formats.

> [..]
> it practically means nuts codec id is seperate and we have
> to add an entry for every codec, and with your deep sense for sanity,
> no seriously i agree that the fourccs you and oded select are more sane
> then whats in avi but it will cause nut and avi to use very different
> fourccs, and that ends the common codec id or common table, i mean
> how much of the table matches avi? none of the audio tags, mp4v no
> h263 no match at fourcc.org, ...

When I sent my second proposal, I meant to use 'DX50' or 'XVID' or 'FMP4', 
but I couldn't decide which to use which wouldn't make us look like 
idiots... (With 'FMP4' we sound elitist, forcing our codec tag to our 
container, and with any other we just sound stupid...)

What would the correct one be for 'h263' btw? It's what I found in 
mplayer etc/codecs.conf ...

- ods15