[NUT-devel] Fourcc spec

[Michael Niedermayer]

Hi

On Sun, Dec 24, 2006 at 09:03:00AM +0000, Måns Rullgård wrote:
> Oded Shimon <ods15 at ods15.dyndns.org> writes:
> 
> > On Sat, Dec 23, 2006 at 09:13:59PM +0000, M?ns Rullg?rd wrote:
> >> Oded Shimon <ods15 at ods15.dyndns.org> writes:
> >> 
> >> > On Sat, Dec 23, 2006 at 03:09:24PM +0200, Oded Shimon wrote:
> >> >> On Sat, Dec 23, 2006 at 01:56:29PM +0100, Michael Niedermayer wrote:
> >> >> > if the lists are not normative that i bet every commercial company will
> >> >> > use their own fourcc divx, 3ivx, ...
> >> >> > why?
> >> >> > 1. the company can better claim that its their own supperior technology
> >> >> > 2. they dont need to bother to implement the standard correctly, its enough
> >> >> >    if their decoder matches their encoder, this is what has happened with
> >> >> >    codecs in avi and as its less work = less money it will happen again.
> >> >> >    It didnt happen with mpeg-ps/ts just because there are too many hw
> >> >> >    decoders around which cant be updated that easily all IMHO
> >> >> > 
> >> >> > if my hypothesis turns out to be true then 3. would loose the 
> >> >> > "single fourcc per codec" and ""Sane" codec names" as in practice the
> >> >> > majority of videos would not use the recommanded fourccs
> >> >> > 
> >> >> > so that brings us to option 4 which would require a player to only support
> >> >> > a codec if the one and only standard fourcc where used, if a unknown fourcc
> >> >> > is used demuxing it would be a violation of the spec ...
> >> >> > 
> >> >> > if that would prevent the issue iam not sure though ...
> >> >> 
> >> >> The list IS normative for demuxers, not for muxers. This was already in my 
> >> >> original proposal, I forgot to re-mention it here.
> >> >
> >> > To spell it out again:
> >> >
> >> > A muxer SHOULD use the fourcc from the codec list
> >> > A demuxer MUST support the fourcc from the codec list if it supports the 
> >> > codec at all
> >> >
> >> > Which means demuxers can have additional fourcc's to the ones in the 
> >> > official list, and a muxer can do whatever it wants. But obviously, both 
> >> > are better off using the official list.
> >> 
> >> This makes no sense at all, but I think you already knew my opinion...
> >
> > Actually, no, I'm confused by your reply...
> > I was slightly off - the demuxer is better off using as many fourcc's as 
> > it wants, but it MUST include also the official list. The muxer, in most 
> > cases, is better off using only fourcc's from the official list, so it has 
> > garuntee of demuxers supporting it. I fail to see how this does not make 
> > sense. I don't know if you noticed, but I'm going through this entire 
> > thing only because of you, I personally do not care. So please, present 
> > your arguments.
> 
> 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 ...


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

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

Republics decline into democracies and democracies degenerate into
despotisms. -- 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/20061224/4c59f22e/attachment.pgp>