[Ffmpeg-devel] integrating AVS decoding into MPlayer

Måns Rullgård mru
Fri Jul 14 21:25:09 CEST 2006


Reimar Doeffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:

> Hello,
> On Fri, Jul 14, 2006 at 09:05:43AM +0100, M?ns Rullg?rd wrote:
>> > And what about remuxing into e.g. avi?
>> 
>> There is no avi fourcc defined for avs, so it can't be done.
>
> MPlayer just defines some fourcc for it, and then it can be done.

But nobody else will be able to play it.  Just hijacking an unused
value is the microsoft way of doing things.  We don't want to be like
them now do we?

>> 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.
>
> Or FOURCCs that are based on the ones for AVI but extended as needed...

Then the additional ones should be kept in a private table somewhere
separate from tables used when muxing.

>> 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.
>
> Well, if you want the AVI table to be confined to the officially
> registered FOURCCs that is right.

Ideally only the official ones would be needed, whatever they are.  In
practice, it is necessary to also recognize nonstandard codes used by
various encoders.  That doesn't mean that contributing more to that
mess is appropriate.

> Is that what your objection was?

Partly.  I also think it is an incredibly bad idea to base an entire
player around the codec ids used by any single container format,
especially such an ill-defined one as avi.

> In that case I guess the best solution would be if MPlayer defined
> another table for its "special unoffical AVI fourcc hack" ones.
> But on the other hand, what does ffmpeg do with snow and FMP4? Those
> aren't official FOURCCs either?

They are not, and FMP4 was never a good idea IMHO.

>> There is *nothing* fundamental about those goddamn fourccs.  As soon
>> as you realize that, your life will become so much easier.
>
> No certainly not. I think you misunderstood me somewhere. I think the
> reasoning for MPlayer is that if at all possible anything should be
> possible to remux into AVI

I don't see how this forces the player to solely use avi fourccs
internally.

> (since mencoder only really supports that),

It's mistake.

> thus everything must have a FOURCC

The reality is that not everything does.  Some things have none at
all, and some have many.  Some fourccs mean different things in
different avi and mov.  In fact, I see no reason to expect otherwise.

> and thus that can be used to "identify" the codec (actually it only
> identifies a group of compatible codecs between which the user can
> select).

This would be true if there existed some central authority assigning
fourccs to all codecs, without ever missing one, or if mplayer were
the only player in the universe.  Neither is true.

> After all I had the impression you were attacking MPlayer for using
> FOURCCs to identify codecs,

I was.

> which IMHO isn't one of the worst choices

As choices go, I consider it quite bad.

> in MPlayer (interpret that however you want ;-) ).

Possibly.  I've seen main().

> I guess the reason for the misunderstand is that I assumed that remuxing
> into AVI if technically at all possible would be a must for ffmpeg, too.
> If that's not the way you want it in ffmpeg then you are right, MPlayer
> must be changed a bit.

Being able to stuff anything into avi is one thing, making that
ability the center of one's universe is another thing entirely.  The
former may be useful at times.  The latter is outright crazy.

Now please don't take this personally.  You just happened to be
standing in my line of fire.

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




More information about the ffmpeg-devel mailing list