[MPlayer-dev-eng] DxVA in MPlayer

[Uoti Urpala]

On Wed, 2010-11-24 at 00:03 +0200, Georgi Petrov wrote:
> > 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.

I implemented something like that for VDPAU - not a variable-sized
buffer, but having at least two frames being decoded at the same time
(as opposed to sending one frame for decoding, waiting for decoding to
finish, showing the frame and only then starting decoding of the next
one). This is mentioned in VDPAU documentation and does improve
performance somewhat; apparently the different hardware units needed for
decoding can be used more efficiently with some amount of pipelining.


> 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.

If you want to create a top-quality acceleration implementation then you
may be better off starting from the git tree where I did the VDPAU
changes. At least that VDPAU implementation is the best currently
available implementation of any acceleration API; and I'd expect some of
the architecture improvements to be useful for DxVA too.