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

Mark Thompson sw at jkqxz.net
Sun Nov 29 01:17:38 CET 2015


On 28/11/15 23:14, Andy Furniss wrote:
> Mark Thompson wrote:
>> On 28/11/15 21:31, Andy Furniss wrote:
>
>>> Looks like it's a gallium thing - I run git mesa and there have been a
>>> few changes around va/vaapi recently.
>
> <snip>
>
>> Ok: in the absence of any evidence that the problem is on the mplayer
>> side, I will ignore this?
>
> I am not really qualified to say whether it's mplayer or not - as per my
> other post mpv doesn't seem to have any issues.

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.


> I crash/assert instantly with the new patch in the case of anamorphic.

Yuck.  Were you ever able to play one stream repeatedly in the same 
instance of mplayer (-loop 0) with any of these patches?  This change 
should be (mostly) equivalent to doing that with the previous version.


I think both of those stacktraces are saying that the VAAPI context 
isn't in a good state:

> VO: [vaapi] 720x576 => 720x576 MPEG-2 VA-API Acceleration
> VO: [vaapi] 720x576 => 1024x576 MPEG-2 VA-API Acceleration

In this one it looks like the hwaccel context hasn't been initialised 
properly when we try to decode, so something nasty happens inside ffmpeg.

> VO: [vaapi] 1440x1080 => 1440x1080 H.264 VA-API Acceleration
> VO: [vaapi] 1440x1080 => 1920x1080 H.264 VA-API Acceleration

In this one it asserts because there aren't any free surfaces for it to 
give to ffmpeg.  Unless you actually got some output, I think we 
probably don't have any surfaces at all because the reinit after the 
output resolution change didn't work.



More information about the MPlayer-dev-eng mailing list