[MPlayer-dev-eng] DxVA in MPlayer

[Uoti Urpala]

On Wed, 2010-11-24 at 10:37 -0500, Laurent wrote:
> On Tue, Nov 23, 2010 at 7:43 PM, Uoti Urpala <uoti.urpala at pp1.inet.fi> wrote:
> > 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.
> 
> You could spare the "top-quality" and other "best of any" subjective statements.

The "best of any" is not subjective, at least for MPlayer codebase (the
code doesn't have readback support so someone who places particularly
high priority on filters could prefer the VLC implementation). The code
improves on the svn VDPAU implementation in several ways, and other
implementations for MPlayer codebase are worse than that.

If you're objecting to quality comparisons in general then I consider
that unreasonable; "start from the best existing code" should be a valid
approach, and for that it matters what the relative quality is.

> What architecture improvements are you talking about?
> Or rather: what do you think are the current limitations of mplayer
> regarding DxVA?

I mentioned one likely relevant architecture improvement in the mail
you're replying to: support for buffering/pipelining in VOs (this
requires higher-level support outside individual VOs for timing to work
right). The timing improvements also allow proper handling of frames
added by hardware deinterlacing (in svn such frames have no individual
timing and are skipped in framestep for example). There are some general
cleanups to the video API. Some other features are less directly
connected to video acceleration but could be important depending on the
intended use, such as the ability to make a VO support changing OSD
contents on top of an existing frame.