[MPlayer-dev-eng] DxVA in MPlayer

[Georgi Petrov]

Hi guys,

Laurent's results are quite disturbing, but they can be result from
poor (yet) Intel WDDM drivers, especially knowing that the XP/DxVA 1
work okay on the same h/w. We will figure it out by comparing with the
Atom + ION solution, which obviously has a driver from nVidia.

We worked out the details and I can start implementing DxVA support
this Thursday. Laurent figured out that VLC's approach is much slower
(CPU usage) on the target hardware and sooner or later we will need
MPC-HC's (no readback) approach anyway for maximum acceleration.

I suggest starting this way.

Of course I don't want to impose my opinion, but since DxVA 1 +
overlay is in the requirements I have, eventually non-readback
implementation will be needed anyway (DxVA 1 doesn't support
readback).

Additionally, since subtitles won't be a real problem (I will make
everything possible not to introduce a new presentation method,
besides current 4), I think that this will work out.

I'm open to suggestions.

> Uh, from my opinion that makes that "DXVA does not work. Let's forget
> about it". But I guess I am just a bit allergic against crappy products
> lately.

Laurent said that 1080p on GMA500 works fine in XP/DxVA 1/MPC-HC and
Linux/MPlayer/VAAPI, which means that the GPU itself is capable and we
have enough memory bandwidth as well. nVidia/AMD offerings will most
likely be even better in this regard. I hope this is some specific
issue that will be fixed easily. I will try to communicate with Intel
as well if it turns out to be their problem. I will have to figure out
in the process of development the problem with Win7/DxVA 2 and GMA500.

I will post results from any combination of configurations and players
under both Windows and Linux, as well as in my computer with quite
capable nVidia Geforce. Then we will make some meaningful assumptions.

Before I receive the h/w, I can start implementing the EVR, I guess.
The h/w will consist of Atom + GMA500, Atom + nVidia ION (I think) +
PCI-E Geforce for development on my computer.

I will have plenty of configurations to develop and test DxVA on.

> Hm, I realize you can probably get that with DXVA as well by decoding
> a few frames ahead and trying to keep a buffer.
> So if a frame took twice as long as it should the buffer size would
> just shrink by one but things would still be smooth, and the buffer would
> hopefully fill up again over time.
> Of course it's not quite as easy to implement I guess, and it only
> helps if it actually is the decoding that is the issue and not
> e.g. memory bandwidth.

Yes, this sound quite logical. I will investigate it when I get to
this point. We already know that the bottleneck isn't memory
bandwidth, because we have two smoothly working test cases (XP/DxVA
1/MPC-HC and Linux/MPlayer/VA API.

So, I want to start from this Thursday. What would you suggest as a
starting point? I will download the latest tree, will compile it and
will fork the D3D renderer, create a new libvo renderer from it and
start with EVR implementation specifics.

Any recommendations?