Re: [MPlayer-dev-eng] VAAPI/X11 video output driver
- Date: Tue, 1 Dec 2015 23:01:53 +0000
- From: Mark Thompson <sw@xxxxxxxxx>
- Subject: Re: [MPlayer-dev-eng] VAAPI/X11 video output driver
On 30/11/15 20:48, Roberto Togni wrote:
On Mon, 30 Nov 2015 11:30:19 +0100
Alexander Strasser <eclipse7@xxxxxxx> wrote:
thank you for your work!
On 2015-11-29 18:39 +0000, Mark Thompson wrote:
On 29/11/15 11:43, wm4 wrote:
On Sun, 29 Nov 2015 00:17:38 +0000
Mark Thompson <sw@xxxxxxxxx> wrote:
I didn't see that before my previous message. I guess I could have a
look at mpv to see what happens differently, but that could be an
arbitrarily large timesink. Unclear how to proceed.
mpv's vo_vaapi is based on the mplayer-vaapi repo's (just as your
patches), but in addition to mpv's changes over mplayer in general, the
vaapi code has been heavily changed. mpv also doesn't recommend using
vo_vaapi at all, but prefer vo_opengl EGL interop instead. The vaapi
video output API is pretty crap and tends to be buggy. It doesn't
prevent tearing in all cases either. I don't think anyone at Intel
really cares about the output API.
Well, how should we actually continue here, then?
The bugs in the libraries/drivers might get fixed eventually. I
am not a vaapi user so I cannot comment on performance and quality
of output. I fail to see what it buys us to be overly pessimistic...
And after all the MPlayer video output is modularized, so no one
is forced to use vaapi for output.
The mplayer-vaapi-derived version is perfect for me on all the platforms I
personally have (only Intel), but clearly fails on some others. The
problems Andy had did let me fix one issue which I hadn't found, but mainly
show that it doesn't work properly for him. Given that most of it isn't my
code, I have little clue what I should be looking at to fix it. I would be
happy if it were accepted as-is (with known problems), or if someone else
could like to take it over to try to fix the breakage.
I think we could accept your current version of the code as a
start, given it works for you and another person (Andy) that have
tested it. I think it might be a start. IIRC Roberto pointed out
some issue with using globals for initialization.
Maybe Roberto can test/review your current version?
I'm on it; this may take a few days, but I should be able to look at it
latest over the long weekend.
Anyway I agree to commit some version of VAAPI support even if not
perfect, it's better than let the patch rot on this list.
Alternatively, the original independent version I wrote* is much simpler (no
OSD, no alternate output types), and as a result might be more likely to
work because there are fewer things to go wrong (particularly around
combining surfaces, which it doesn't do). If people would prefer that then
I could relatively easily clean it up to a testable state? (Also fixing some
of the problems found in the other version.)
Note that my actual aim here is to get sensible VAAPI encode in ffmpeg, and
I would prefer not to get excessively distracted from that. I was hoping
that writing the mplayer driver would be a good first step in understanding
how those pieces fit together, and could also have some value in itself.
(If anyone is interested, I have a working but ill-integrated VAAPI decode
helper for ffmpeg (allows accelerated decode when transcoding - not very
useful in itself).)
That is the bigger problem. If we are going to integrate
your code, IMHO we still need someone "looking after it";
a maintainer for that code in MPlayer. E.g. like someone who
regularly compiles MPlayer with vaapi and uses it and is
subscribed to at least this mailing list.
I can compile it, but I won't use it much (I can decode h264 in
software anyway, and newer codecs like hevc and vp9 are not supported
on my hw).
I intend to use this (am already using it, even), and I'm happy to
commit to regularly compiling/testing it as well. It's a huge gain
against software decode on weaker Intel hardware, particularly on all of
the low-power Atom-type chips such as the Braswell N3700 I have been
MPlayer-dev-eng mailing list