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

[Mark Thompson]

On 28/09/16 11:47, Andy Furniss wrote:
> Andy Furniss wrote:
>> Andy Furniss wrote:
>>
>>> 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.
>>
>> Still happens with your libav patch 1 and 2 reversed.
>>
>> No matter what I try it seems that mkv + hwupload will be seen as 1000 fps.
>>
>> With mp4 it's 25fps.
> 
> Oops ignore the mp4 bit, it is possible to get that to work - no luck with mkv
> so far though.
> 
>>
>> Also the same with a mkv not made by me, these file all play at correct
>> rate and are seen by avconv -i or mediainfo as correct.
>>
>> I guess there is a difference between reading the fps from the container
>> vs reading from the stream.

VAAPI CBR does not support VFR input; you end up with the 1000fps because that's
the time base inside your input file and we have no way of knowing at init-time
what the frame timestamps are going to be.  To make it work, either use CQP
(which works sensibly with VFR streams if the container supports them), or make
the stream CFR - this is probably easiest by adding "-r 42" (or similar) as an
output option.  The mp4 output will not exhibit the problem because the muxer
declares in advance that it is CFR-only, so avconv already forces the time base
and timestamps into the right state for it.

Thanks,

- Mark