[Ffmpeg-devel] 4XM audio codec_tag
Mon Nov 6 02:38:38 CET 2006
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
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
More information about the ffmpeg-devel