[Ffmpeg-devel] 4XM audio codec_tag

[Baptiste Coudurier]

Reimar D?ffinger wrote:
> Hello,
> On Sun, Nov 05, 2006 at 04:30:02PM +0000, M?ns Rullg?rd wrote:
>> Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
>>> If mplayer cannot dectect CODEC_ID_ADPCM_4XM, use a conversation table
>>> between CODEC_ID_ADPCM_4XM and whatever mplayer wants to use as internal
>>> fourcc.
>>>
>>> This is becoming more and more problematic...
>> It's only a problem because mplayer is really an AVI player with
>> support for other formats shoe-horned on as an afterthought.
> 
> This is obviously the case in some places, but in this case that's not
> what creates the problems.
> How would this be any better if e.g. MPlayer used arbitrarily long
> strings to identify codecs? Of course, we would not meddle with riff.c
> then, but instead we would have to have our own translation table for
> _all_ codec ids, instead of those that do not have a fourcc/twocc
> assigned.

You are just using the fact that mplayer can easily sneak into
libavformat code. Look at vlc/xine...

> And no, using codec ids directly is not a choice unless you decide that
> you will never ever want to use any demuxers or decoders besides those
> from libavformat/libavcodec.
> I'd really be interested to hear a suggestion that is better with a
> convincing explanation why it is better. And as said, hacking riff.c is
> _not needed_ from the MPlayer side, it just seems preferable.
> 

Again, vlc/xine deal with that.
A solution is to first search in riff.c, then have a small table for
codecs which does not have fourcc. That is clean, and would not require
a big table.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312