[Ffmpeg-devel] 4XM audio codec_tag

Måns Rullgård mru
Sun Nov 5 22:47:47 CET 2006


Michael Niedermayer <michaelni at gmx.at> writes:

> the question is what to do with codecs which dont have an entry in the
> table for the target container format,

If that is the case then the codec is not supported in that format.
Tough luck.

> you seem to suggest that the application should simply say "no" in
> that case, but this concept doesnt make sense for generic containers
> like avi or mov the application might warn the user or require a
> command line paramter like -strict -1 but beyond that,

At the very least.  The user should be made aware that what he is
doing is non-standard, and he should be required to explicitly
override the standard if that is really what he wants.  Likewise if
the user is a "she".

> if the user say that he wants 4xm in avi why not mux it?

Because it's not standardized.  We refuse to encode MPEG video with
non-standard frame rates (and rightly so).  Why should we be strict at
the codec level, but ignore every standard at the container level?

> this is like microsofts msmpeg4v3 in avi prevention

Not at all.  What you are suggesting is like the Chinese AVS in MPEG
thing though.  You end up with files that nobody knows how to play,
except yourself.

> if OTOH you have no problem with muxing any codec in avi, then why do
> you complain about them having an entry in riff.c?

I'm complaining about adding entries to the riff.c tables in order for
non-RIFF based formats to abuse those tables.  If there is a genuine
RIFF file that uses some non-standard tag, by all means add to the
table so we can play the file.  That said, we really should have a
flag for each entry to tell whether it is standard or not.  The
AVI/WAV muxers should be modified to not use non-standard entries
(unless explicitly requested).  If we're really lucky, perhaps that
would teach a few people to use other formats than AVI.

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




More information about the ffmpeg-devel mailing list