[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