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

[Mark Thompson]

On 27/09/16 16:48, Andy Furniss wrote:
> 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 =

Easily fixed: <https://lists.libav.org/pipermail/libav-devel/2016-September/079372.html>.


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

I'm not really sure how fast I should be expecting this stuff to work - can you offer any numbers about how fast it goes for you?  I only get ~30fps doing 1080p transcode on an R7 360, which compares rather badly to ~240fps on the Skylake 6300 in the same machine.


> 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

Hmm, this is an error on my part.  I'll fix it, but I need to test a bit further to be sure I'm not breaking anything else.


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

That code is just wrong, isn't it?  It works for pic_order_cnt_type == 2, but it needs to look at the pic_order_cnt_lsb and delta_pic_order_cnt values on the slice header for other cases.  (Looking at gstreamer, it has POC type 0 (as I do), but then the POC values match what POC type 2 would create in the no-B-frame case, so this happens to work.)

I'll see if I can make a patch for this.


Thanks,

- Mark