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

[Mark Thompson]

On 30/11/15 20:48, Roberto Togni wrote:
> 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
>

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

Thanks,

- Mark