[MPlayer-dev-eng] VAAPI/X11 video output driver
Mark Thompson
sw at jkqxz.net
Wed Nov 25 00:55:26 CET 2015
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).
* 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.
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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vo_vaapi.20151124.patch
Type: text/x-diff
Size: 108171 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20151124/ef51b499/attachment-0001.patch>
More information about the MPlayer-dev-eng
mailing list