Mplayerosx

I was under the impression that CoreVideo was the preferred video output. I'm curious, where did you hear otherwise? I have been compiling mplayer with --disable-gl, and I believe Adrian does as well, but if performance can be improved under OpenGL, it certainly merits investigation.

Unfortunately I don't have access to my development PC for the time being, so am back to square one of just trying to get mplayer to compile again, but I'll definitely be looking into this.

And if you make any progress in this area I'd certainly like to hear about it.

I have gotten -vo gl and -vo gl2 to work under mplayer2, though the latter looks terrible for some reason. Rather than post pages of instructions of what I did I'd rather hear where exactly you are having troubles and addressing them specifically.

Unfortunately OpenGL output launches an X11 window, and does not properly go fullscreen. I am unfamiliar with X11 or OpenGL, but I'd like to restore OpenGL output as an option in MPlayer OS X. From my limited benchmarking, the opengl output does appear to be less CPU intensive (25-50%) than CoreVideo, but I am not sure if the video quality is the same, and the inability to go fullscreen or display in the player window are deal-breakers for now.

I'd really appreciate some help on this if you are still interested, because integrating OpenGL into the front end is not going to be easy.

Update: It looks like the gl2 video output is deprecated, so forget about that. I tried compiling mplayer2 with SDL as an OpenGL backend rather than X11, and fullscreen works much better that way. It is slow in going to fullscreen though, and the window doesn't display video until I move it. Though for gl output to be useful I need it to output to a shared buffer as corevideo does.

I still haven't gotten gl output to work with the MPlayer.app frontend without spawning an additional process in the Dock. Annoyingly this additional process launches even if I am using CoreVideo. Merely compiling an mplayer binary with SDL support causes the secondary Dock icon to be present no matter what vo is used...

I am now trying to investigate the problem from the other end; seeing if I can improve CoreVideo rather than OpenGL. I believe the problem is one of the following:

1. CoreVideo is doing software scaling. OpenGL output uses hardware scaling, and does not call the swscaler video filter.
2. CoreVideo might be doing software colorspace conversion, but I think the scaling is more likely to be causing the slowdown.

This is still way over my head, and CoreVideo might be too high level of an API to actually add the necessary hardware-level calls that the gl output uses, but I'll keep working on it.