[Ffmpeg-devel] 4XM audio codec_tag

Michael Niedermayer michaelni
Sun Nov 5 22:23:09 CET 2006


Hi

On Sun, Nov 05, 2006 at 09:00:14PM +0000, M?ns Rullg?rd wrote:
[...]
> >> > The best I can make of this criteria is that, except for the audio
> >> > fourccs, there is no reason not to include any of them here, because
> >> > as soon as we add them to MPlayer they are used in AVI.
> >> 
> >> Does the phrase "format bastardization" mean anything to you?  Do you
> >> know what the word "standard" means?
> >
> > So what do you suggest? Keeping to the standard? Only allowing the tags
> > that are in the official Microsoft registry? I don't mind, that is a
> > clear criteria, and won't really hurt MPlayer. But I find it hard to
> > image that this is really what is wanted.
> 
> Since the official registry is badly maintained, and many (most?) 
> files in the wild use other tags, a somewhat relaxed approach has to
> be used with AVI.  A sensible solution would be to use a table with
> all the registered tags, plus commonly used non-registered tags.  When
> writing files, registered tags should of course be used in preference
> to non-registered tags.  This is sort of how lavf handles AVI now,
> although I don't know which of the tags are actually officially
> registered.
> 
> This is not where we are disagreeing though.  I don't mind adding
> non-standard tags to support playing existing files.  What I do mind
> is using the AVI codec ID table for *other* formats that have nothing
> to do with AVI.  Your justification for doing this appears to be that
> there is often a significant overlap between the sets of tags used in
> different formats.  If two formats use the same tags, and are always
> guaranteed to do so (e.g. by the spec for one of them referring to the
> other for codec tags), then sharing the tables is the correct thing to
> do.  If, on the other hand, there is only some overlap (such as
> between AVI and MOV), sharing the tables is wrong.  Just because some
> formats use tags of the same size, and even happen to use the same tag
> for some codecs, doesn't make applying the union of all the tag sets
> to all the formats correct in any way whatsoever.
> 
> Does any of the above make sense to you?

we have seperate tables for mov and avi
the question is what to do with codecs which dont have an entry in the
table for the target container format, 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, if the user say that he wants 4xm in 
avi why not mux it? this is like microsofts msmpeg4v3 in avi prevention

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?

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