[NUT-devel] Fourcc spec

[Michael Niedermayer]

Hi

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

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


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


> 
> > 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
and nut seems to be on the way to double that work, if its table is
split off sufficiently

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

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

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)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is