[FFmpeg-user] h264_vaapi missing frames
Mark Thompson
sw at jkqxz.net
Wed Mar 21 13:17:13 EET 2018
On 20/03/18 10:24, Kai Hendry wrote:
> Hi Mark,
>
> On 20 March 2018 at 17:58, Mark Thompson <sw at jkqxz.net> wrote:
>> Show your command line? The pts values in that file are quite uniform, suggesting that you've forced the output to be treated as if it is 30/1001 fps even if it isn't. The status line also says "frame= 529 ... dup=430", which I think means it has captured 100 frames and made 430 duplicates to keep the framerate.
>
> Sorry, I've just discovered -report.
>
> https://s.natalian.org/2018-03-20/1521541273.mp4.log
> https://s.natalian.org/2018-03-20/1521541273.mp4
>
> https://github.com/kaihendry/recordmydesktop2.0/blob/vaapi/x11capture
> is the script in question.
>
> Does that better tell you what I'm doing wrong?
The -re option might be causing problems there - it is meant to be used for pretending that a file is a real-time source, not for actual real-time sources (see the documentation at <http://ffmpeg.org/ffmpeg.html#Advanced-options>, which warns against doing exactly this). With that option removed I would expect it to use the real timestamps from x11grab which hopefully gives better results.
If that doesn't work then I suggest reducing the test case to find which parts are causing the problem - e.g. try without audio, using libx264 instead of VAAPI, without extra video sync ("-vsync 0").
- Mark
Aside: the command you have there does colour-conversion on the CPU (x11grab makes bgr0, the format filter there makes it convert to nv12 before upload). It is possible to do the conversion on the GPU instead by putting a conversion after hwupload, which is often faster: "-vf 'hwupload,scale_vaapi=format=nv12'" (though note that this has less control over colourspaces, so the colours can be a bit wrong in some cases).
More information about the ffmpeg-user
mailing list