[NUT-devel] Fourcc spec

[Rich Felker]

On Fri, Nov 17, 2006 at 06:42:19PM +0100, Michael Niedermayer wrote:
> > > if this gets accepted we have surpassed avi and mov in brokenness
> > > several seperate codec id systems
> > 
> > I don't follow. There is no "several different codec id systems"
> > proposed here. This is intended as a normative list of names. For
> > video the established, sane, implementation-independent fourcc should
> > be used. What a spec like Oded has proposed should be interpreted as
> > meaning is:
> > 
> > 1. If you're making a NUT player and it supports one of the codecs
> >    listed here, it MUST accept the codec_id listed if it accepts any
> >    codec_id at all.
> > 
> > 2. If you're writing a NUT file using a common codec listed here, then
> >    you had better use the listed codec_id or there's no reason to
> >    expect that any conformant NUT player will be able to play it.
> > 
> > 3. If the codec was not popular/not listed before, you might have
> >    previously used another codec_id for it for whatever reason, e.g.
> >    because two parties independently were the first to put the codec
> >    in a container and didn't know what the other was using. There's no
> >    reason to forbid players from accepting this alternate codec_id
> >    (since a multi-format player will already have other names in its
> >    tables anyway, and since such files may be useful). But such
> >    codec_id values should be considered as deprecated.
> > 
> > Again there is absolutely no "multiple systems" concept being
> > proposed. The intended use of avi-like fourcc has always stemmed from
> > the (correct!) assumption that any multi-format player will already
> > have a large table of four-byte codec identifiers that can be unified
> > across the vast majority of container formats (since they don't use
> > conflicting identifiers). 
> 
> you can unify such a table for demuxing/decoding but if we accpet odeds
> first proposal then we need 2 lists for muxing as mp4s/mp4v, mp3 and so
> on are not good choices for avi, while they would be the best choice for
> nut -> you end up with 2 tables / 2 systems 

Yes but this will always be the case unless you propose using "DX50"
for mpeg4 video... Certainly "DX50" is the preferred fourcc for avi
since many shitty settop players only support 'divx'... If you don't
care about them then the preferred fourcc would probably be "FMP4" or
"XVID", which are equally nonsensical for NUT.

IMO the point of Oded's and my design is to avoid the "broken
monopoly-enforcing settop player" problem by making the mandated
codec_id an implementation-neutral one. This seems to be what we
agreed upon all along.. I don't see what's changed by Oded writing
this document; can you explain?

> 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.

Rich