[MPlayer-dev-eng] [PATCH] dvdnav part 3 - emptyframe
Michael Niedermayer
michaelni at gmx.at
Tue Jul 31 16:13:05 CEST 2007
Hi
On Tue, Jul 31, 2007 at 01:56:00PM +0200, Reimar Döffinger wrote:
> Hello,
> On Tue, Jul 31, 2007 at 12:16:42PM +0200, Michael Niedermayer wrote:
> > On Tue, Jul 31, 2007 at 11:17:27AM +0200, Reimar Döffinger wrote:
> > > On Tue, Jul 31, 2007 at 12:05:22AM +0200, Diego Biurrun wrote:
> > > [...]
> > > > libmpeg2 used to be faster than FFmpeg. The last time I made benchmarks
> > > > years ago this was indeed still the case, but FFmpeg was catching up.
> > > > Baptiste keeps telling me that FFmpeg is faster nowadays, but we really
> > > > need extensive benchmarks to confirm or deny this.
> > >
> > > Just yesterday I was shocked to see that ffmpeg12 + vo_gl on Windows is
> > > about 30% slower than libmpeg2 + vo_gl.
> > > Probably I am doing something stupid in vo_gl (I guess that with
> > > PCI-Express slice-based rendering becomes very slow in comparison), but
> > > it still is a huge difference.
> >
> > uhm ... 30% ...
> >
> > it would be interresting to know what exactly causes this speed difference
>
> -noslices fixes it mostly btw. I didn't make proper measurements though.
btw, vo_gl.c get_image does
if (mpi->flags & MP_IMGFLAG_READABLE) return VO_FALSE;
if (mpi->type == MP_IMGTYPE_IP || mpi->type == MP_IMGTYPE_IPB)
return VO_FALSE; // we can not provide readable buffers
isnt the 2nd if wrong? i mean if MP_IMGFLAG_READABLE isnt set then the
decoder shouldnt read from the buffer
(note writes could cause cache lines to be fetched if things arent
configured correctly ...)
also if draw_slice (many glUploadTex) is so slow while a single glUploadTex
is fast then maybe allocating a buffer get_image() style and then
memcpy_agp / memcpy into that for each slice might be faster ...
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070731/18689fc3/attachment.pgp>
More information about the MPlayer-dev-eng
mailing list