[NUT-devel] Fourcc spec

[Oded Shimon]

On Thu, May 31, 2007 at 03:20:38AM +0200, Michael Niedermayer wrote:
> On Wed, May 30, 2007 at 06:47:47PM +0300, Oded Shimon wrote:
> > 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...

[..]

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

I am willing to make a list for all codecs currently in avocdec.h - that 
is all that would be relavent for a muxer in ffmpeg anyway. I also 
talked to Mans here at LT, we agree to maintain this list, "into the 
forseeable future"...

- ods15