[MPlayer-dev-eng] a few nut suggestions [fourcc and codec identification]

[Michael Niedermayer]

Hi

On Sunday 03 October 2004 22:19, D Richard Felker III wrote:
[...]
> 5. fourcc and codec identification
>
> i'd like to rethink the way we identify codecs, especially for audio.
> most of the m$ fourccs for audio are incredibly stupid (just arbitrary
> numbers with no string meaning) and in fact they're ambiguous with
> regard to nut's header structure.
>
> in the traditional header structures in riff-based formats (avi and
> wav), the original idea was that data was uncompressed, so the header
> described the sample format really closely with useless stuff like
> bytes-per-sample, signed/unsigned, etc. with compressed data, fields
> like this are meaningless, since different decoders could in principle
> (and will in the future!) output different formats. so i agree with
> the way nut is doing things now, not including that mess.
>
> but, with uncompressed audio we're left with a big problem. there's
> just one fourcc for pcm, and it doesn't specify the sample format at
> all. so we have basically two choices: one is to make up and include a
> codec-specific header for pcm that tells the sample format, and the
> other is to make up our own fourccs for each sampleformat (like S16L,
> S16B, U8LE, FLLE, ...). i'm not sure which is better in principle, but
> if we're already going to make up sane fourccs for audio rather than
> using the m$ junk, it wouldn't hurt to make separate pcm fourccs while
> we're at it.

agree (1 fourcc <-> 1 specific raw format)

btw, for video there is a similar problem, while YUV formats have their own 
fourcc rgb formats all use fourcc=0 IIRC

[...]
-- 
Michael

"I do not agree with what you have to say, but I'll defend to the death your
right to say it." -- Voltaire