[Ffmpeg-devel] 4XM audio codec_tag

[Michael Niedermayer]

Hi

On Sun, Nov 05, 2006 at 11:48:08PM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > Hi
> >
> > On Sun, Nov 05, 2006 at 09:36:57PM +0000, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:
> >> 
> >> > Hello,
> >> > On Sun, Nov 05, 2006 at 09:00:14PM +0000, M?ns Rullg?rd wrote:
> >> >> Does any of the above make sense to you?
> >> >
> >> > It's mostly about getting something more specific than whether it makes
> >> > sense.
> >> 
> >> I just don't understand how you guys can find it so unimportant to be
> >> accurate.  Ever heard of interoperability?
> >
> > yes, and we loose alot of interoperability if we dissaow every
> > demuxer to try list of common codec_tag -> codec_ids (=riff.c)
> 
> Why should the RIFF tags be given this special status?  Why not have
> all demuxers search the codec lists for *all* formats while we're at
> it?

iam perfectly fine with using all too


> 
> >> > I on the other hand was mostly thinking of completely new formats, like
> >> > all of those game formats, that do not usually appear in AVI.
> >> > E.g. if the line
> >> > vst->codec->codec_tag = MKTAG('R', 'J', 'P', 'G');
> >> > was removed from nuv.c (which it probably should), then should an entry
> >> > for it be added to riff.c?
> >> 
> >> I'd say no.  We have no choice but to include some nonstandard tags if
> >> we want to support all the files out there.  That does not mean we
> >> should be contributing to the mess.
> >
> > we contribute by not having a tag there,
> 
> How do we contribute to the mess by refusing to write non-standard files?
> 
> > if a user wants to have 4xm in avi he will mux it in avi
> 
> If his apps refuse to do it he won't.

how hard is it to grep for an error message and comment the exit(0) or
return -1 below? you dont need to know much C for that

if you wish to prevent the user from doing things (s)he wants to do
then you shouldnt write open source software


[...]
> >> > I would tend towards: better clutter the table a bit and support more
> >> > formats however rare than having a cleaner table.
> >> 
> >> Again you've drifted from the question of sharing the codec ID table
> >> between unrelated formats, and treating the RIFF table as some kind of
> >> absolute reference.
> >> 
> >> Just face the facts: formats use different tags to identify codecs, no
> >> matter how much you pretend that all of them use the RIFF values.  The
> >> only way to properly handle this is by using one codec tag table per
> >> format.  End of story.
> >
> > i have no problem with one table per format, what i have a problem with
> > is that libav* would fail decoding a file if no match is found and that
> > it would leave the codec tag decission to the end user and not suggest
> > a default one if theres none in the one table for the target format
> >
> > if OTOH there is one table per format and a default fallback table then
> > thats something different with which iam fine
> 
> A "fallback table" doesn't make any sense at all.  None.  Zero.  Nil.
> Either a format supports some particular codec, in which case its ID
> table will have an entry for that codec, or the codec is not
> supported, in which case failure is the only sensible option.
> "Suggesting" to use a tag from some other random format instead is
> utterly senseless.  Such behavior is what created the AVI mess in the
> first place.

avi is a generic container its supposed to be possible to store anything
in it (with a few exceptions)
the same is the case for mov, matroska and nut
there is nothing messy with that

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