[MPlayer-dev-eng] Video controls for mplayer, smplayer and direct3d under win32 [ver 0.6.7]

Georgi Petrov gogothebee at gmail.com
Mon Apr 20 10:52:34 CEST 2009


Hi Tom,

I can speak about direct3d. Each driver should implement video
controls by itself using the available hardware capabilities. direct3d
still doesn't implement (I was working on it, but I'm graduating and I
doesn't have time right now) hardware brightness/contrast/etc.
controls.

By "implement" I mean this - MPlayer has a video control API, which
gives the video out driver the exact user required
gamma/brightness/contrast/etc. correction coefficients. Then the video
out driver should "talk to the other side", i.e. the overlay in case
of directx (DirectDraw) or the Direct3D API in case of the direct3d
driver.

Directx (DirectDraw) uses hardware overlay. The hardware overlay (or
simulation of it in the vendor driver (ATI/nVidia/Intel) in case it is
missing in the real hardware) has exposed brightness/contrast/etc.
controls as simple as a modifiable 0-255 (for example) values.
Directx's work is pretty easy as it receives correction coefficient
from the MPlayer API and just modifies the corresponding coefficient
on the other side (the HW overlay controls). Voila - the video on the
screen is altered.

Unfortunately in the Direct3D API that direct3d video out driver uses
there are no such controls exposed by the API and I have to use
pixel/vertex shaders on each rendered frame. This is A LOT of extra
work from my point of view. I'll do it someday, don't worry :)

By adding the eq2 filter, it is inserted in the decoding chain between
the decoded video in RAM and the video out driver. All subsequent
changes to the video controls is handled by the eq2 filter. The video
out driver is not bothered. The problem is that eq2's code is running
on the CPU and not the GPU hardware itself (as those corrections would
in case of video out driver's implementation). That's why you will
notice higher CPU usage by doing this.

The point of implementing these control in the video driver is to
offload those calculations from the CPU and move them on the GPU.

You see that adding the eq2 filter in the chain is a cheap way to work
around drivers that doesn't implement hardware video controls, but it
doesn't mean it's the right thing to do considering CPU time.

I hope your question is answered. Feel free to ask anything else :)



More information about the MPlayer-dev-eng mailing list