[NUT-devel] Fourcc spec

[Rich Felker]

On Sat, Nov 18, 2006 at 01:43:33AM +0100, Michael Niedermayer wrote:
> > 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. 
> 
> if someone wants to play just divx generated mpeg4 they just need to check
> for the divx user data string
> but i don think any manufactor really wants that ... its rather lack of
> knowledge of the other mpeg4 fourccs, its insane but did anyone actually
> contact the manufactors which produce set top boxes and dont support 
> xvid, fmp4 or others? if not then adapting a format to workaround that
> seems not the correct solution

arrg, there is no "adopting a format to workaround" going on. it's
designing a format correctly so that this issue never arises with it
in the first place.

> > This seems to be what we
> > agreed upon all along.. 
> 
> yes probably, i cant remember all the details of the fourcc flames :)
> 
> 
> > I don't see what's changed by Oded writing
> > this document; can you explain?
> 
> it changes what is currently written in the spec ...

how so? all it does is add a requirement that a compliant player
support these codec_id values if it supports the corresponding codecs,
which seems to have been our intent all along even though it was never
written into the spec.

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

this seems to be a totally separate issue from nut...
i don't see why their incessant flaming should be relevant to nut.

> and nut seems to be on the way to double that work, if its table is
> split off sufficiently

imo not. but even if it does double the work for a multi-format
_muxer_, it will not increase the work at all for a multi-format
player. the latter is what matters most. lavf is probably the only
'universal' muxer in existence and it will probably remain that way
for the forseeable future.

> if the user has to manually select fourccs for codecs not in the nut 
> table then it will cause an incredible mess as everyone will
> choose a different fourccs

are you sure? yes maybe this is a bad idea; it was just a random
suggestion.

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

yet they're already in the fourcc table of mplayer and any other
player that uses a common table, presumably.

as for audio, what's used in quicktime? can we adopt that without
introducing stupidity?

> so at that point i really think we should rethink about what we want
> to do, if we make our own table then so be it if not then AVI should
> be used and only avi,

imo it's no problem to derive from the union of all 32bit alphanumeric
codec id tables.

> if we dislike something then it
> should be added to the avi table thats just IMHO ... avi doesnt have
> any "you may not add your sane fourcc rule" ...

agree, we should ignore the flames by måns and baptiste and add the
sane names to the riff/avi tables, and encourage their use in avi as
well... :)

alternatively we could make a bitfield for each fourcc to flag that
it's illegal in certain formats, with the default being legal in all
formats. but this is an implementation issue, not an issue of nut
design.

> OTOH maybe simply making our own table would be simpler (not technically
> but in the flameability sense) we start with whats on fourcc.org and
> you and oded change what you dont like (iam fine with anything no matter
> if its dx50 for mpeg4 or mp4v or fmp4, iam not fine mp4s as thats not
> standard compliant mpeg4 AFAIK but MS shit)

iirc mp4s was supposed to mean standards-compliant, as opposed to
mpg4, mp42, mp43, etc. which were ms crap. however i think it got
bastardized somewhere along the time and quicktime uses it for
something else. so i agree a different name should be chosen. i'm
strongly opposed to any of the implementation-specific names though.
as soon as you go down that path, you wind up with the trouble of
players omitting support for certain implementations and then
implementations must lie that they're actually a different
implementation...

rich