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

[Mark Thompson]

On 30/11/15 21:01, Roberto Togni wrote:
> 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.
>

Similarly, but it's there in libva and ffmpeg so presumably it works for 
someone.  The support here is trivial, so I'm inclined to just leave it 
in even if noone can test it.

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

Hmm.  I don't really mind which way we go here.  If the current form 
with an extra output format on each hwaccelerable decoder can interfere 
with anything else then dropping it would be sensible, but currently its 
use completely depends on the vo so I don't see how anything bad can 
happen.  Hence I'm inclined to leave it on the grounds that the user 
actively chose vaapi output and therefore might know what to blame if it 
goes wrong (unless I'm misunderstanding, it's not going to be picked 
normally unless a lot of other normally-working things aren't there).

The one actual deficiency that I see is that there is no way to force 
software decoding with vaapi output when a compatible hwaccel is 
present, but that's a rather absurd case I can't see any use for.  If 
the output-only part is desirable then we could easily add an extra 
option "nohwaccel" (say) which would entirely disable the decoder setup 
and force software decoding.

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

Would it be preferable to just entirely remove them, then?  It would cut 
the size of the change by a lot and make me somewhat happier that I 
understood how it was all working.

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

Thanks,

- Mark