[MPlayer-dev-eng] DxVA in MPlayer

[Laurent Aimar]

On Fri, Nov 19, 2010 at 11:11:53PM +0100, Reimar Döffinger wrote:
> On Fri, Nov 19, 2010 at 10:53:21PM +0100, Laurent Aimar wrote:
> > > 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.
> >  You won't have to touch the libavcodec library but you will need to
> > modify the code in mplayer that calls FFmpeg.
> 
> That wasn't necessary for any of the other acceleration formats and
> I'm very close to saying there's no way I'll allow any Windows-specific
> code in there.
 Then it probably means that the mplayer code directly ask the vo to fill
the surfaces pointer. If so, it will also work for DXVA2 (except that then
with the current FFmpeg code, you need a dedicated renderer).

 Anyway, I don't really know the mplayer code, but the DXVA2 code in FFmpeg
behave exactly like the one for VAAPI, so you should be able to simply copy
the way that VAAPI is supported in mplayer (non read back mode).

> >  I would think that doing the read back first might be easier as you
> > would modify less mplayer code (ie the code you need to write would only
> > touch vd_ffmpeg.c).
> 
> "Modify no MPlayer code" IMO absolutely must be the goal for this.
> Having half a decoder in FFmpeg and the other half in MPlayer without
> a technical reason is at the very least a maintainance nightmare.
 FFmpeg current API forces the caller to setup all the data needed for the
accelerator, that means that for now you need to have specific player code
to use it (wherever you put it). It's the same for VAAPI/VDPAU. There are
some patches on the FFmpeg mailing list to start changing that but I haven't
looked closely at them.

 Anyway, with DXVA2 API (I think you have the same issue with VAAPI, dunno
about VDPAU), you cannot completly let FFmpeg initializes everything it needs
at least in the case when you don't do read back. For example, the
IDirect3DDeviceManager9 for DXVA2 is shared with the renderer (and must be
allocated by the renderer). It's the same for the Direct3DSurface array.

 On the other hand, I think that some part of the code in VLC could be moved
to FFmpeg (to reduce code duplication). But I don't have enough experiences
outside the read back mode to be sure of which part (until I find time to
implement the non read back mode in VLC, or until someone provides patches ;)

-- 
fenrir