[MPlayer-dev-eng] DxVA in MPlayer

[Georgi Petrov]

Hi,

Thanks for the positive and fast feedback. I will answer and ask new
questions to all your mails in this one.

Let me start with the VLC vs MPC-HC DxVA implementation issue. The
first one decodes each frame and then reads back the contents from the
GPU for processing (filters, etc). It is slower, but behaves like a
normal video codec. I understand the trade-off. Reimar suggested this
approach.

The second one renders directly the decoded frames from the GPU on the
screen without any possible post processing. Faster, but less
flexible.

However, the organization/person which contacted me about this project
wants to use the implementation for low-power nettop Atom based
devices, where performance per watt (as I suppose) is a primary
concern. As they will provide the hardware and specification
requirements, I have to meet them with a priority.

I suggest to implement DxVA in MPC-HC way (no read back, faster, no
post-processing/filters) first. It will be initially easier as well
and I will learn a lot of details. After the company' requirements are
met, I can/may implement the read back method as well. I hope that you
agree that starting and making work the easier and more accessible
approach (no read back) is better at least in the beginning.

I saw the code today and I didn't suppose that FFmpeg guys have done
so much work. This is just great! DxVA 2 accelerated codecs (as I call
them) for H.264, VC-1 and MPEG-2 are already written!!! They don't
really decode anything, but "prepare" the bitstream from the file into
a suitable way for the DxVA VO. Is this right?

As I understand it, I will have to implement only the VO (in a libvo
library). Please, correct me in this one - I won't have to write any
codec specific code (in libavcodec library). Is this right? My
observations say so.

At least for H.264, VC-1 and MPEG-2.

The whole logic will be based inside a new vo_dxva2.c for example,
which will setup an EVR custom renderer. Then when this vo_dxva2 is
used, the correct codec from libavcodec will be selected (the
accelerated H.264, VC-1 or MPEG-2), which will provide my VO with a
prepared bitstream (and not with decoded frames) and I willl send the
bitstream to the DxVA API. Is this right?

I mentioned VDPAU/VA API not because I want to use them in any way
(this is impossible), but to understand if the infrastructure they use
is the same as the future DxVA VO will use. As I see, this is exactly
the case. Please, correct me if I'm wrong again: for VDPAU for example
there is another libavcodec "codec", which prepares the bitstream from
the actual file in a suitable way for the VDPAU VO. Is this right?

In a way the VDPAU implementation has:
1. libavcodec "codecs" for H.264, MPEG-2, VC-1, which prepare the
stream for the VDPAU VO.
2. libvo implemented VO, which is combined with the codec from above.

I suppose that the VA API patches follow exactly the same pattern with
respective libavcodec/libvo parts?

With DxVA the situation is the following:
1. libavcodec "codecs" for H.264, MPEG-2, VC-1, which prepare the
stream for the DxVA VO. They are already written.
2. libvo DxVA VO I have to write, which will take the prepared stream
from the codec above and send it through EVR custom renderer on the
screen.

If all this is right, I have one other question:

In case I start this project from the EVR custom renderer and I want
it to work with a normal (non-accelerated codec), I will have to write
the VO in way that accepts data both from a non-accelerated (already
decoded frames) AND in the same time from an accelerated codec? Is
this right?

If so, wouldn't it be easier to write the EVR custom renderer to take
only DxVA supplied bitstream from the accelerated codecs? In the end
the EVR custom renderer makes sense to  be used only together with
DxVA "codec", as it provides no advantage to the Direct3D renderer...

Thanks for telling me the people involved from the other players. I
will surely contact them and ask their opinions about the amount of
work I have to do. Tomorrow I will continue with reading more code and
trying to make my own estimates.

H.264 / VC-1 are my primary target, but not the only one. Currently
FFmpeg doesn't seem to support DxVA decoding for MPEG-4 ASP
(DivX/XviD). I suppose it will be too hard for me to add it? It is one
of the last requirements, but I suppose I should ask the FFmpeg
developers about this one?

One more - DxVA 1 H.264 support (for Windows XP) is also required.
Using the hardware overlay (vo_directx). In case you don't know - DxVA
1 doesn't require EVR renderer and can be used with both overlay and
the Direct 3D renderers. Are there any complications expected about
this one? I suppose I will have to make a slight changes to these
renderers? The problem is that FFmpeg doesn't seem to support DxVA 1
at all, so I suppose that this question is better suited to their
developers, right?

Thanks guys, I really want to make it and it seems pretty doable as well!