[MPlayer-dev-eng] DxVA in MPlayer

[Reimar Döffinger]

On Fri, Nov 19, 2010 at 11:20:41PM +0200, Georgi Petrov wrote:
> 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.

Um, in that case the GPU and CPU memory are likely to be shared,
and there shouldn't be much if any performance issue with
choosing the "readback" method.
And Atom isn't sufficiently low-power that readback should change
much concerning that.

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

Um, that depends on what the goal is. If they actually want/need
subtitle support as well I doubt it.

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

Yes, but don't underestimate that if you want it to be good-quality.
The direct3d one did take some time to become stable, and this one
seems more difficult.
Since I do not really know anything about EVR, subtitles/OSD might
even be a lot more difficult...

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

Yes. You must also make sure that "direct-rendering" is used to pass
the data (since the VO usually needs to allocate the buffers)
and you need to select the right "IMGFMT" (and do not forget to
change IMGFMT_IS_HWACCEL, that will take care of some special
handling, in particular enabling direct rendering and making
sure vf_scale doesn't try to handle it).

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

Mostly. I think it is a bit outdated in regard to some thing.
IMO particularly the vo is a bad example to follow.

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

It's a bit more convoluted than that, I guess you'll have to get surfaces,
and how many depends on the number of reference frames and then
you have to display them in the correct order (not the same you passed
them in). It should be described well enough in some documentation though.

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

Advanced features like hardware deinterlacing may be or may become
available through EVR at some point and are rather unlikely to be
available via Direct3D. But I don't know what exactly the status
is there.

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

The cannot necessarily help, you'll need someone who knows which format
DXVA needs for ASP.

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

I thought both versions use the same format.
You'll have to double-check that though.
The more critical question though is: can you assume VLD-level decode
support?
Because supporting partial acceleration will be a huge pain,
and Atom makes it sound like it is an Intel solution and I seem
to remember that only partial (iDCT basically) acceleration is
supported for VC-1, but no bitstream parsing.
Which IMO makes the whole thing useless, at least for Blu-ray
bitrates that's not going to be low-power anymore...