[MPlayer-dev-eng] [RFC] internal library copies
michaelni at gmx.at
Thu Mar 18 19:29:40 CET 2010
On Wed, Mar 17, 2010 at 07:50:08PM +0100, Reimar Döffinger wrote:
> > * libmpeg2
> > Nowadays FFmpeg is faster and should be better maintained. Unfortunately
> > we cannot compile against the external version. This should not be hard
> > to fix. If it gets fixed, we could remove libmpeg2 IMO.
> > Is anybody interested in fixing external libmpeg2 compilation?
> Not particularly, but I wonder when FFmpeg got faster?
> IIRC it was always slower... Of course that might depend on the CPU,
> libmpeg2 only supports up to SSE I think, so with CPUs that support
> more than that libavcodec probably has a chance.
what i remember and that was that way for a long time was that
libavcodec was faster for some files/cpus/gcc versions and
slower for others.
I also remember that we could gain a sizeable speedup by just throwing
non mpeg2 code out of the codepath. (gcc doing something really silly
here, the speed difference was quite a bit bigger than what one would
expect from the execution of the occasional if(0))
also i remember keiji working on this but i dont think anything usefull
came out of it.
If someone wants to make our decoder faster iam willing to help & review
patches, but i wont spend my time trying to beat libmpeg2 for all files,
this is silly
wasted time that i could spend better like trying to make h264 beat all
closed source decoders ...
Besides my offer for a write account to walken still stands if he wants
one. He would be a great help in h264 optims for example or he could
port all the tricks from libmpeg2 or even add external libmpeg2 support
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the MPlayer-dev-eng