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

[Mark Thompson]

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.
>>>>
>>>> I posted a patch some time ago, that ports the VAAPI support from the
>>>> mplayer-vaapi fork. It supports OSD, GL, filters, and some other
>>>> things. If you want to look at it you can find it here
>>>> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2015-October/073163.html
>>>>
>>>>
>>>> It also uses globals to pass the hwaccel context, but only because I
>>>> was lazy; the original code used a VOCTRL for it.
>>>> It's tested only on vaapi 0.36 (version in debian stable) on a
>>>> sandybridge; I don't have any newer processor.
>>>>
>>>>
>>> Oops, I sent this before reading your answer to Compn.
>>>
>>> Ciao,
>>>   Roberto
>>
>> 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).
>
> 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).
>> * Removed stats.[ch], they aren't really relevant.
>> * 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
>
>>
>> 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 haven't usefully tested the other output options: gl and xrender
>> look like they work, but are outwardly indistinguishable to me.
>> * Tearing is visible.
>>
>> 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.
>>
>>
>> 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.
>>
>
> Thanks,
>
> - Mark
>

Now tested on an old Cantiga GM45 Intel Graphics chipset (pre-Quick 
Sync), which only does MPEG-2, and a Bay Trail (graphics like Ivy Bridge 
but weaker).

So, working on at least:

Debian Stretch, VAAPI 0.38:
Cantiga GM45:    MPEG-2
Haswell 4500U:   MPEG-2, H.264, WMV3, VC-1
Braswell N3700:  MPEG-2, H.264, WMV3, VC-1, H.265

Debian Jessie, VAAPI 0.36:
Bay Trail J1900: MPEG-2, H.264, WMV3, VC-1

Ubuntu 14.04, VAAPI 0.35:
Haswell 4790:    MPEG-2, H.264, WMV3, VC-1

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.

- Mark