[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