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

[Andy Furniss]

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

Ugh, yea, after spending far too much time messing around with input it
was output format that made the difference.

On bench marking - your 30 vs 250 does seem low. If you haven't tried
setting gpu and cpu to perf maybe that will help. It helps with my tonga
sometimes.

If it's a dual GPU system that may add complications as I recall  seeing
a bug report where someone had issues with prime + powerplay/dpm.  I
can't remember what the GPU was though.

Some quick benches with a 1000 frame 1080p 15M source transcoding h/w
dec + h/w enc -qp 28.

avconv 129 fps

gst vaapi 242 fps

gst omx 271 fps.

I am using the maxrefs patch, so I don't really know why gst is doing
better.

It's worse if I start with rawvid and use hwupload.

avconv 89 fps

gst vaapi 243 fps

gst omx 305 fps

 From messing around with x11grab I already knew ffmpeg/libav seems to do
some extra copy that gstreamer doesn't, possibly tmpfs is also read
quicker. It's an issue for screen recording not just benchmarking, maybe
you saw the threads on ffmpeg lists.