[MPlayer-dev-eng] [PATCH] DivX6 support

[Rich Felker]

On Tue, Jun 20, 2006 at 09:32:55PM +0300, Ivan Kalvachev wrote:
> >DivX 6 support would be interesting to make codec comparisons, but is it
> >faster than libavcodec?  I doubt it...
> 
> Is libmpeg2 faster than libavcodec ffmpeg12?

Last I checked the answer is still a big yes!

> Long time ago I flamed you because something you pretend to be
> clarification removed a quite remarkable rule "Do not remove, just
> improve". Now I have to fight every your attempt to remove some part
> of mplayer only because you feel like it.

There's a difference between removing functionality and removing code
duplication or cruft.

> 1. Strange Files. divx4_vbr.* are under GPL, you can read the file. If
> you remove them, remove and xvid_vbr.* I may be wrong, but I think
> these are part of universal 2pass code for all codecs that doesn't
> have their own 2pass mode.

AFAIK no such codecs are supported anymore. At least none which are
compatible with the divx4_vbr.* files.

> 2. License. At some point DivXNetwork people claimed they've gpl-ed
> the decoder (opendivx). I cannot find proves atm, and it could have
> been just claim. However the gpl clause from divx4_vbr.c must have
> come from somewhere.

No idea, don't care.

> 3. Compatibility. Old codecs also produced streams with bugs. These
> bugs could lead to image corruption. Indeed lavc support workaround
> for some, but loading it with all bugs from all ancient codecs would
> only slow it down. And some old videos are really hard to find.

libavcodec already supports decoding all these broken stream formats,
and will continue to add support for more workarounds as they are
found without slowing down the case of decoding correct streams.
Requiring ancient legacy code that probably does not even compile
anymore in order to decode rare-but-existant old streams is not
acceptable, especially when that code is (semi-?)proprietary.

> 4. Maintenance. As I've said before these peaces of code doesn't
> trouble anybody or anything. They don't need regular maintenance (aka
> cleaning the dust, changing the oil). They work as they always had.

Is this really true? IMO having cruft/legacy code around makes it more
painful to overhaul the source... things like adding pts support
become much more painful when you have to update useless legacy codecs
that no one understands or cares about to conform to the new api.
People would be more likely to try and implement new features if they
didn't have to retrofit so much crap to work with the new features.

> 5. Dominance. MPlayer is "One tool to rull them all". Keeping codecs
> out of it or removing codecs out of it would just cripple it. We need
> to support these codecs at least for been able to compare them.

Removing duplicate implementations is not crippling. We've already
removed many duplicate implementations (like libmatroska,
libmpcodecs/native/*, ...) when better alternatives became available.
There's no reason to stop doing it now. If we leave all this useless
cruft in place, MPlayer source will grow without bound like Linux and
become impossible to download on slow connections, painful to archive,
etc.

The fact that we regularly run over our bandwidth quotas makes this
even more important! We should remove whatever useless crap we can in
order to keep the tarball size down.

> A reason for codec support removal could if they are broken and nobody
> is up to fix them.

Or if they duplicate existing more-general functionality and provide
no advantages.

> DonDIego, please stop thinking what else you can remove from MPlayer.
> And please if you want to remove something start a new thread that
> says so, not hiding it into threads about adding stuff.

This is not Diego v. Ivan. This is Ivan v. sanity. Please take your
personal issues with Diego somewhere else.

Rich