[Ffmpeg-devel] integrating AVS decoding into MPlayer

[Måns Rullgård]

Rich Felker <dalias at aerifal.cx> writes:

> On Fri, Jul 14, 2006 at 09:05:43AM +0100, M?ns Rullg?rd wrote:
>> Reimar Doeffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:
>> 
>> > Hello,
>> > On Thu, Jul 13, 2006 at 10:11:30PM +0100, M??ns Rullg??rd wrote:
>> >> "Stefan Gehrer" <stefan.gehrer at gmx.de> writes:
>> >> > Von: "M??ns Rullg??rd" 
>> >> >> I don't see how this fourcc gets used.  The files are MPEG PS, and the
>> >> >> lavf PS demuxer detects AVS video without consulting that table.
>> >
>> > And what about remuxing into e.g. avi?
>> 
>> There is no avi fourcc defined for avs, so it can't be done.
>
> Then define one. This is what we've always done in the past.

And it's about time an end was put to that habit.

>> >> > MPlayer's demux_lavf.c calls codec_get_bmp_tag() to translate lavf's
>> >> > codec_id into a codec_tag, and it seems that it does things after that
>> >> > based on codec_tag only, but I might be wrong.
>> >> 
>> >> That's just plain wrong.  Someone needs to fix mplayer.
>> >
>> > What is so wrong about that?
>> 
>> You can't play files using codecs without a defined avi fourcc.
>
> They need to have one defined anyway.

Only if some broken player design needs it.

> It's required for storage in most containers

All containers require some form of codec identifier.  There is no
requirement whatsoever that it match the identifier used in any other
container (unless of course the spec says so).

> including NUT. :)

I was hoping nut might become a clean alternative to all the mess
that's out there.  Well, I guess I can stop hoping for that now.

>> > By switching to codec id instead of fourcc? What would be the
>> > advantage of that?
>> 
>> A player that can handle more than one container format needs an
>> internal codec identification system, be it based on integers,
>> strings, or something else.  Each demuxer has to map whatever id
>> system its container uses to the internal id.  How does mplayer handle
>> mpeg ts codec ids anyway?  Or matroska?  Or ogg?  None of those use a
>> fourcc at all, so they can't possibly be looked up in the avi table.
>
> The internal system is fourcc. Identifiers from other containers are
> mapped to and from fourcc,


> sometimes using internal 32bit identifiers from other containers
> (like mpeg) as a fourcc.

MPEG doesn't have any 32-bit identifiers at all, for codecs or
anything else.

> Whether this latter practice is a good idea, I dunno.

I've been trying to explain why it isn't.

>> There is *nothing* fundamental about those goddamn fourccs.  As soon
>> as you realize that, your life will become so much easier.
>
> It's not fundamental, but universal. Out of the thousand or so codecs
> out there, 99% have a fourcc and about 1% have a matroska identifier.

Some containers use an 8-bit identifier, e.g. MPEG.  Some other use a
16-bit identifier, e.g. WAV.  Yet others use a 32-bit identifier,
e.g. AVI and MOV.  Still others use strings.  There is no reason all
containers with the same size codec identifier will use the same
codes.  In some cases, some of the codes happen to coincide, but this
should not be taken to be by design.

> This issue was discussed in the NUT development list and that's why we
> adopted fourcc.

Alas...

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