[Ffmpeg-devel] 4XM audio codec_tag

[Michael Niedermayer]

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)


[...]
> 
> > 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, if a user wants to have 4xm in avi
he will mux it in avi theres -vtag and -atag to set codec tags no need for
a table, the user can override it, and if theres no entry then every user
will invent one, that mess is several magnitudes bigger


> 
> > MPlayer has long supported that format in avi I think,
> 
> So what?

iam against droping support for decoding existing files


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

[...]

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