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

[Mark Thompson]

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

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

This also fixes a reinitialisation bug - the previous version of this 
patch failed to come back correctly if two software-supported but not 
hardware-supported (MPEG-4 on Intel, say) streams with exactly the same 
properties were played consecutively.

See attached for the whole patch.

Thanks,

- Mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vo_vaapi.20151128.patch
Type: text/x-diff
Size: 104443 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20151128/82bb9b0f/attachment-0001.patch>