Web lists-archives.com

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

On 30/11/15 21:01, Roberto Togni wrote:
On Sat, 28 Nov 2015 16:55:48 +0000
Mark Thompson <sw@xxxxxxxxx> 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@xxxxxxxxx> 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
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
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.

* 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

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




- Mark

MPlayer-dev-eng mailing list