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

[Roberto Togni]

On Mon, 30 Nov 2015 11:30:19 +0100
Alexander Strasser <eclipse7 at gmx.net> wrote:

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

Ciao,
 Roberto