[Ffmpeg-cvslog] r6963 - trunk/libavformat/riff.c

[Michael Niedermayer]

Hi

On Sun, Nov 12, 2006 at 04:40:56PM +0000, M?ns Rullg?rd wrote:
> Diego Biurrun <diego at biurrun.de> writes:
> 
> > On Sun, Nov 12, 2006 at 06:33:59PM +0200, Oded Shimon wrote:
> >> On Sun, Nov 12, 2006 at 05:31:49PM +0100, Diego Biurrun wrote:
> >> > On Sun, Nov 12, 2006 at 05:22:11PM +0200, Oded Shimon wrote:
> >> > > On Sat, Nov 11, 2006 at 03:08:40AM +0100, Michael Niedermayer wrote:
> >> > > > 
> >> > > > On Sat, Nov 11, 2006 at 01:22:08AM +0000, M?ns Rullg?rd wrote:
> >> > > > > michael <subversion at mplayerhq.hu> writes:
> >> > > > > 
> >> > > > > > Log:
> >> > > > > > libnut uses "MP3 " for mp3
> >> > > > > >
> >> > > > > > Modified: trunk/libavformat/riff.c
> >> > > > > > ==============================================================================
> >> > > > > > --- trunk/libavformat/riff.c	(original)
> >> > > > > > +++ trunk/libavformat/riff.c	Sat Nov 11 01:29:49 2006
> >> > > > > > @@ -200,6 +200,7 @@
> >> > > > > >      // for NuppelVideo (nuv.c)
> >> > > > > >      { CODEC_ID_PCM_S16LE, MKTAG('R', 'A', 'W', 'A') },
> >> > > > > >      { CODEC_ID_MP3, MKTAG('L', 'A', 'M', 'E') },
> >> > > > > > +    { CODEC_ID_MP3, MKTAG('M', 'P', '3', ' ') },
> >> > > > > 
> >> > > > > Nooooo.  We were trying to get rid of those invalid bogus tags from
> >> > > > > riff.c.  Don't add more of them.
> >> > > > 
> >> > > > nut per spec uses the avi-riff tags to identify codecs, libnut uses
> >> > > > "MP3 " ...
> >> > > > ask oded why
> >> > > 
> >> > > I actually don't know myself. Ask Rich, he told me to do it. :/ BTW, I use 
> >> > > "mp3 " (no caps).
> >> > 
> >> > Fix libnut then?  And I agree that this is confusing.  Does NUT use the
> >> > same identifiers as AVI, 0x55 then, or not?
> >> 
> >> It used to be 0x55 .
> >
> > .. and what does the spec say? ..
> 
> It says nothing at all, because the authors refuse to fully specify
> the format.

the spec:
-----------
fourcc
    identification for the codec
    example: "H264"
    MUST contain 2 or 4 bytes, note, this might be increased in the future
    if needed
    the id values used are the same as in avi, so if a codec uses a specific
    fourcc in avi then the same fourcc MUST be used here
-----------

IMO this is clear, and actualy much clearer then the iso/itu specs which
hardly anyone can decypher, just look at h.264, you end up reading a
paragraph 3 times until you realize their obfuscated stuff means the pixel
to the left of the current one ...

if anyone, diego, the wanderer or anyone else has suggestions on improvements
for the text above or any other part of the spec, these would definitly be
welcome

also clearly pointing to problems so they can be fixed is very welcome
what is not welcome is trollish "It says nothing at all"
i understand that you disslike avi/riff and thats all fine, everyone
hates some things but i think you go a little to far here with these
unspecific attacks, if you have technical arguments against something
please say them ...

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

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is