[MPlayer-dev-eng] [PATCH] new mpeg muxer

D Richard Felker III dalias at aerifal.cx
Mon Feb 28 21:02:23 CET 2005


On Mon, Feb 28, 2005 at 08:31:44PM +0100, Arpi wrote:
> Hi,
> 
> > IMO the problem on your system is what someone else mentioned: the
> > buggy "QuickTime" video layer on osx converts yv12 to yuy2 behind the
> > scenes, using very slow code, and also gamma corrects it in software
> > which is incredibly slow and unnecessary.
> 
> it's imho even worse. at least on my g5, it seems qt converts the
> yv12 image to rgb, so when doing big scaling (ie. 320x240 ->1280x1024)
> you can see big aliasing effect on colors, like if you first convert to
> to yuv 4:4:4 (or rgb) and then scale up using linear scaling...
> 
> knowing, that quartz extreme (in osx 10.3.x) does every screen rendering
> through opengl, i can imagine it first converts yuv to rgb, and then
> uses the opengl renderer to scale it up...
> 
> > > Using Mplayer is usually OK, but I tend to prefer using Quicktime. QT 
> > > has better rate control and syncs better with audio.
> > 
> > Must be due to bugs on the mac vo/ao drivers..
> > 
> > > There is now a nice vo for mplayer called quartz, which is not really 
> > > using Quartz (display PDF vector compositor) but Quicktime.
> > > AFAIK noone has ported vidix to Mac. X11 on Mac is dog slow.
> > 
> > Are you sure vidix isn't supported? It would be by far the best
> > choice.. Maybe someone (I know there are plenty mac fans out there!)
> > could port it....
> 
> afaik it isnt ported, and even if so, it would be hard to make it
> stable, as the os keeps updating the screen using full hw accel.
> (so there may be conflicting registers/commands on the gpu)

Using the overlay doesn't rquire commands on the gpu, just setting a
few registers. I can't see how this would conflict..

Anyway thanks for the comments. It's good to have solid facts on why
OSX sucks beyond imagination.

Rich




More information about the MPlayer-dev-eng mailing list