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

[Alexander Strasser]

Hi Mark,

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 at jkqxz.net> 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?

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

> * Attached to the first post in this thread <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2015-November/073190.html>.


  Alexander