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

[Andy Furniss]

Mark Thompson wrote:
> 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>.

Great, thanks.


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

I'll have to come back on this one tomorrow as it's late here.

I started to get some numbers but found a possible bug = I made a 1000 
frame 15mbit 1080p50 mkv with ffmpeg/libx264.

Using it as source for transcode (s/w or h/w dec) it came out far too 
low bitrate.

After re-applying debugging patch to mesa it turns out that framerate is 
being set as 1000 in the encoder, I don't know if the file is duff or if 
it's the patches.

more tomorrow.

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

My knowledge of low level detail is not so good.

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

Thanks.

>
>
> Thanks,
>
> - Mark
>
>