[MPlayer-dev-eng] VAAPI/X11 video output driver

[Roberto Togni]

On Sat, 28 Nov 2015 16:55:48 +0000
Mark Thompson <sw at jkqxz.net> wrote:

> On 25/11/15 21:22, Mark Thompson wrote:  
> > On 25/11/15 12:08, Mark Thompson wrote:  
> >> On 24/11/15 23:55, Mark Thompson wrote:  
> >>> On 24/11/15 23:11, Roberto Togni wrote:  
> >>>> On Wed, 25 Nov 2015 00:04:19 +0100
> >>>> Roberto Togni <rxt at rtogni.it> wrote:
> >>>>  
> >>>>> Thanks for the patch, I will look into it in the next days.  
[...]
> >>>
> >>> Ok, here's my attempt at combining the useful features of the two
> >>> (mainly stealing from your side).  I hope you weren't too attached to
> >>> the original, because I have rather mutilated it here :)
> >>>
> >>> Notable changes against your version:
> >>> * H.265, WMV3 added and tested.  H.263 added but not tested (no
> >>> hardware).  
Good. I'm not even sure that supporting H263 is meaningful at all.

> >>
> >> Build with older libva would fail because of lack of H.265 (ffmpeg
> >> HEVC_VAAPI_HWACCEL can't be set without libva header support).
> >>
> >> New version with fixed configure attached.
> >>  
> >>> * Removed the requirement for any extra options to run (just use -vo
> >>> vaapi).  
I'm not sure about this.
I'm not happy about having two hwaccel systems (VAAPI and VDPAU) with
different commandline invocations.

From an usability point of view it's good to not having to force the
codec, but I would keep anyway an enable switch for hw decoding (so
using something like -hwdec vaapi -vo vaapi). This will easily allow to
skip hw decoding if it's not working properly; also since hwdec is atm
not compatible with filters and such, user will experience unexpected
failures if hwdec is enabled by default behind their backs.

Forcing vo may be enough, but the hwaccel vo (both vaapi and vdpau) can
work also without hw decoding now. I have no idea how widespread is
this kind of usage.


> >>> * Removed stats.[ch], they aren't really relevant.  
Ok

> >>> * Replaced the ffmpeg decoder driver code with my version, which was I
> >>> think somewhat cleaner (probably a biased opinion).  The hwaccel context
> >>> is still passed through a VOCTRL because I can't see a way of doing that
> >>> which isn't worse than the global, but giving it a weak stub removes the
> >>> linker problem.  
> >>
> >> * still /not/ passed  
I have an idea about this, but it requires to allocate the codec in the
vo like my version did.
My long-term idea is to move all hwaccel code out of vd_ffmpeg into its
own vd_ffhwaccel to avoid all the special cases.

For the rest of the changes, the target of my version was to minimize
modifications to the other accelerators, since I could do only minimal
testing.

> >>  
> >>>
> >>> Tested with H.264, VC-1 and WMV3 in Quick Sync on Haswell (4500U) and
> >>> Braswell (N3700); additionally tested H.265 on Braswell (the hybrid GPU
> >>> decode).  Both Debian Stretch (testing), VAAPI 0.38.  
> >>
> >> Plus H.264 on Haswell (4790) in Ubuntu 14.04, VAAPI 0.35.
> >>  
> >>>
> >>> Remaining problems:
> >>> * The error checking is still terrible.  
I will have a look, but we can improve this later.

> >>> * I haven't usefully tested the other output options: gl and xrender
> >>> look like they work, but are outwardly indistinguishable to me.  
I didn't tested them.

> >>> * Tearing is visible.  
I never noticed it with my version on i7 sandybridge and va0.36, will
test it also with your version

> >>>
> >>> Also, I'm still somewhat dubious about how the reference picture
> >>> management works, and the number of surfaces used.  I suggested it was
> >>> actually wrong in the other thread, which is I think unfounded, but I
> >>> still don't entirely understand how MP_IMGTYPE_NUMBERED is interacting
> >>> with the surfaces being used for output.  
iiuc there are 2 ways of handling the surfaces in the vo driver, and
this is autoselected if not forced.

> >>>
> >>>
> >>> Could you have a go with this?  If you still have a nonworking stream,
> >>> I'd be happy to look at it to try to work out what's going wrong.
> >>>  
For non-working most samples I already found the issue: they are not
supported on my hw (eg. mpeg4).
The only nonworking samples that I will have to retest are some wmv3.

[...]
> >
> > In all cases it also sensibly plays back unsupported videos (MPEG-4
> > tried) without decode acceleration.
> >
> > How old a libva is it useful to support, anyway? Checking that should
> > probably be in the configure test.
> >  
> 
> Based on a survey of current Linux distributions, the oldest libva 
> version in a usefully-supported distribution is 1.2.1 (in openSUSE 
> 12.1), with VA-API version 0.34.  Correspondingly, I now check for that 
> version at configure time and reject older versions.  Support for those 
> has been removed, too, and the only thing which remains conditional is 
> H.265 support (requires 0.37).  
I agree with it, since supporting >=0.34 avoids the compatibility header

>   
[...]

Ciao,
 Roberto