[NUT-devel] Fourcc spec

Michael Niedermayer michaelni at gmx.at
Thu May 31 03:20:38 CEST 2007


Hi

On Wed, May 30, 2007 at 06:47:47PM +0300, Oded Shimon wrote:
> Hi from Linuxtag!
> 
> On Wed, Dec 27, 2006 at 11:54:40PM -0500, Rich Felker wrote:
> > On Sun, Dec 24, 2006 at 01:21:00PM +0100, Michael Niedermayer wrote:
> > > > Having a list makes no sense unless it's normative for both sides.
> > > 
> > > agree though thats a statement and not a argument
> > > the argument ("proof" by contradction) is that if the muxer can choose any
> > > fourcc for standard mpeg4 (not buggy near mpeg4 ...) then a demuxer cannot
> > > support mpeg4 in nut with 100% certainity, theres the very small possibility
> > > that mpeg4 would be stored with another new and unknown fourcc ...
> 
> Does this mean that we want a spec after all which is normative both for 
> muxers and demuxers?
> This would mean, there would be a single table in the nut muxer 
> implementation, and if muxing a codec which does not have an entry in the 
> table is attempted, muxing would fail. - The resolution would be to 
> contact us and the codec would be officially added to the list, and then 
> it could be muxed, until then it would be impossible.
> 
> I am not against this, as - this is a bikeshed issue... What are your 
> opinions on this? Rich, Michael, please reply...
> 
> > > btw, one interresting goal of the codec id system should be:
> > > the system must be generic so that
> > > 2 users who otherwise cannot communicate can mux and demux a codec X in nut
> > > with high propability of success, without manual intervention and assuming
> > > the codec has a de-facto standard fourcc in avi
> > 
> > agree. some thoughts...
> > 
> > - we cannot stop people from inventing their own nonstandard id's for
> >   their bad implementations of (mostly) standard codecs, regardless of
> >   what id system we use.
> > 
> > - aside from such malicious parties, people making nut files will
> >   generally be interested in having their files be playable on as many
> >   players as possible.
> > 
> > - if we provide a list of officially sanctioned codec id's for
> >   standard codecs, and require any conformant player to support these
> >   id's if it supports the codec in question at all, then (1) we can
> >   officially flame anyone making a player that omits support for the
> >   standard name, and (2) people intending for their files to be widely
> >   playable will use the standard name since other names might not be
> >   supported by settop devices, etc.
> > 
> > - players wanting to provide maximum compatibility will also support
> >   various broken names for codecs, but this provides no significant
> >   implementation difficulty in complexity, size, or performance.
> > 
> > it's for these reasons that i want to stick with what oded has been
> > saying. the only question in my mind is _which_ names should we agree
> > upon as the standard ones????
> 
> If we do the above suggestion - spec is normative for muxers, then the 
> answer is fairly easy - use our own new "clean" fourcc list. I would see 
> no argument against this, as NUT would have its own completely fixed and 
> seperate table...

do we have a list that contains everything from http://www.fourcc.org/ ?
do we have at least 2 volunteers who dont mind maintaining that list
indefinitly ?

if the awnser is no to either of them then we dont need to disscuss the
possibility of a normative list which is centrally controlled as we fail
on the basic requirements for it ...

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- 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/20070531/5510d06a/attachment.pgp>


More information about the NUT-devel mailing list