[MPlayer-users] [Bug] image tearing

Reimar Döffinger Reimar.Doeffinger at gmx.de
Wed May 23 23:04:41 CEST 2012


On Wed, May 23, 2012 at 12:03:28PM +0100, Christian Ebert wrote:
> * Reimar Döffinger on Tuesday, May 22, 2012 at 21:14:40 +0200
> > On Tue, May 22, 2012 at 12:35:50PM +0000, Zongyao Qu wrote:
> >>> If I was unclear: please update again, I committed a 
> >>> fix for such a bug just yesterday.
> >>> If that does not fix it, we can investigate further.
> >> 
> >> Thank you for this info, I was testing just hours before you committed.
> >> Just now I downloaded the new version, and it is fixed.
> > 
> > Good.
> > 
> >>> This is kind of unrelated, but you might want to compile MPlayer 
> >>> with SDL support and use -vo gl. It can be a lot
> >> 
> >> I would love to, but I am using the sharing buffer
> >> which is built in corevideo.

I looked at it, does that actually work in a usable way? The protocol
seems quite broken, basically it will cause the video to be delayed
against the audio, because the application is not notified when a new
frame is _available_ (i.e. decoding is done) but only when it really
needs to display it ASAP!
There's also some other minor issues such as that no stride is
transferred, so it is not possible to ensure necessary alignment
to make sure it is possible to use SSE or Altivec to process the frame.

> > Unfortunate. Corevideo could really use some cleanup, but with the
> > only Mac in reach being an old PPC the compile speeds etc. are
> > kind of demotivating.
> 
> I found -vo quartz to work slightly better than -vo corevideo.

It's yet slower by a bit on mine.


More information about the MPlayer-users mailing list