[MPlayer-dev-eng] internal libmpeg2 status (and necessity), Linux 2.4 drivers

[Ivan Kalvachev]

On 3/21/13, Diego Biurrun <diego at biurrun.de> wrote:
> Somebody remind me why we still keep a forked copy of libmpeg2 around.
> It's not default and the external one works just fine.  We finally got
> rid of tremor and mp3lib; libmpeg2 should be next to go IMO.

The internal libmpeg2 exports quantization values that are used by
post-process filters (pp, spp, uspp, fspp, etc). The external one
doesn't provide such functionality. (I think you even tried to ask
them nicely).
There are also few hacks that handle rare error cases (like starting
with B frames etc).

Last time you urged Luca to "streamline" the internal lib, in order to
make it equivalent of the external one. Unfortunately most/all his
commits were reverted after users complained from breaking one thing
or another.

I'm not that eager at keeping internal libmpeg2, but on the other
side, I don't see any reason to get rid of it. It is not regularly
broken by new gcc versions, seems quite resilient to bitrot.


> Also, what's with the stuff below drivers/ - the 90s called, they want
> their kernel back :).  I don't think anybody still has a use for that,
> let's kill it.

Actually 2.4.0 kernel is released 2001. The first linux kernel is from 1991.
I'm quite worried at your enthusiasm about killing.


On 3/22/13, compn <tempn at twmi.rr.com> wrote:
> On Thu, 21 Mar 2013 20:40:19 +0100, Diego Biurrun wrote:
>>On Thu, Mar 21, 2013 at 02:16:12PM -0400, compn wrote:
>>>
>>> can you still build ffmpeg against libmpeg2 ? no.
>>
>>That was never possible, you are mixing up libmpeg2 with something else.
>
> oops, you are correct.
>
> i compare ffmpeg v libmpeg2 output on corrupt and rare samples often.
> vlc and xbmc still link against both libs:
> http://wiki.videolan.org/VLC_Features_Formats
> http://wiki.xbmc.org/index.php?title=XBMC_related_projects_and_sites
>
> re drivers:
> i havent used any of those old cards/drivers in years.
> havent seen our resident mga devel around since 2011.
> in #mplayer we still get a few people working with framebuffers and
> such. but i'd say its on newer hardware.
>
> i'd hate to see that code deleted. i wouldnt mind it moved into a
> seperate svn repo and disable it in the configure, if someone wants it,
> svn co to get it working. if you dont like this idea, please articulate
> your reasoning.

I'm ok with that pasture.

Have in mind that drivers/3dfx.h is used by libvo/vo_3dfx.c and
libvo/vo_tdfxfb.c . AFAIR it is part of official driver released by
3dfx (that is probably not ported to latest kernels either, but there
are ports for early 2.6.x).
The latest kernel still have tdfxfb.

There is vo_tdfx_vid.c that seems to use the drivers/tdfx_vid.c .
I'm not sure if vo_mga uses drivers/mga_vid.c, but it likely does.
No idea about drivers/rage128_vid & radeon_vid.