[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