[Mesa-dev] [PATCH] st/va: Fix vaSyncSurface with no outstanding operation

[Andy Furniss]

Mark Thompson wrote:
> On 27/09/16 00:49, Andy Furniss wrote:
>> Mark Thompson wrote:
>>> ---
>>> A simple fix to the problem described here: <https://lists.freedesktop.org/archives/mesa-dev/2016-September/128076.html>.
>>>
>>> With this applied, the driver no longer hangs/crashes when vaSyncSurface() is called in places other than for the first time after an encode operation (including a second call on the same surface).
>>
>> Once I could get ffmpeg (patched) or avconv to roughly work (before the dual instance commit), but I can't get either to work now = produces unreadable file.
>>
>> Testing with git avconv I am trying -
>>
>> ./avconv -vaapi_device :0 -f rawvideo -framerate 50 -s 2560x1440 -pix_fmt nv12 -i /mnt/ramdisk/trees-1440p50.nv12 -vframes 5 -vf 'hwupload' -c:v h264_vaapi -profile:v 66 -b:v 40M  -bf 0 -g 30  -f h264 -y /mnt/ramdisk/out.264
>>
>> but debugging printfs show refs = 2 and bframes enabled (I also notice with your baseline patch that -profile:v 66 fails).
>>
>> Do you have an example that works for you with avconv + this patch?
>
> Yes: this patch <https://lists.libav.org/pipermail/libav-devel/2016-September/079207.html> is also required to match the vaSyncSurface() change.  The rest of the that series to libav and the one to mesa for config setup makes it all a bit more sensible (doesn't submit a load of packed headers which are ignored), but it does mostly work without.

Ok, thanks, so with that I am back to where I was before it stopped working.

In summary baseline works but JM ref decoder doesn't like the pocs.

b frames don't work properly, but then they don't with gst vaapi either. 
They do work with gst omx.

Looking at output from printfs some differences I see vs gstreamer.

maxrefs is hardcoded to 2 which has sideffects =

enc_pic.pc.enc_b_pic_pattern = 1 vs 0 - seems harmless in practice.

There is code that for my h/w disables dual instance when maxrefs > 1 
which means half speed, but there seems to be a bottleneck elsewhere 
that makes avconv 3x slower than gstreamer anyway.

gop, it seems that avconv with -g doesn't set h264->intra_idr_period in 
handleVAEncSequenceParameterBufferType which gets used to set 
context->desc.h264enc.gop_size and enc_pic.rc.gop_size

pocs gstreamer increments h264->CurrPic.TopFieldOrderCnt in 2s avconv 
1s. The code divides this by 2 in handleVAEncPictureParameterBufferType


> With all of those, the commands:
>
> ./avconv -y -vaapi_device /dev/dri/renderD129 -i in.mp4 -an -vf 'format=nv12,hwupload' -c:v h264_vaapi -bf 0 out.mp4
>
> ./avconv -y -vaapi_device /dev/dri/renderD129 -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -c:v h264_vaapi -bf 0 out.mp4
>
> ./avconv -y -vaapi_device /dev/dri/renderD129 -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf 'scale_vaapi=w=1280:h=720' -c:v h264_vaapi -bf 0 out.mp4
>
> work sensibly for me (also with -b for CBR, -qp for CQP, -g for GOP size); I imagine raw video as in your example would also be fine.  On profile, constrained baseline on the command line is 578 (== 66 | 0x200, for constraint_set1_flag).
>
> Thanks,
>
> - Mark
>
>