[Ffmpeg-devel] 4XM audio codec_tag

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> 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

Are you completely out of your mind, or are you just totally ignorant?

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

Anyone who does that can bloody well blame himself if his files can't
be used with other software.  A program/library as distributed to the
user shouldn't knowingly produce invalid files.

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

That doesn't mean we should make it easier for users to do stupid
things, like creating files in violation of the standards.  Of course
we can't completely stop them from doing it, but they should at least
have to put some effort into it.

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

There is nothing messy about a container that can potentially be used
with any codec.  The mess comes when people INSIST ON INVENTING THEIR
OWN CODEC TAGS.  How the f*ck are others supposed to know what those
tags mean if they are not included in some kind of official list?

-- 
M?ns Rullg?rd
mru at inprovide.com