[FFmpeg-user] ffmpeg on Raspberry Pi using h264_v4l2m2m hardware acceleration

[Adam Nielsen]

> The resulting .mp4 is flagged as VFR which is not what I expected nor
> wanted.

I am using v4l2_m2m on a Pi and getting constant framerate (although
still not correct) so it is at least possible:

  Frame rate mode                          : Constant
  Frame rate                               : 13.508 FPS
  Original frame rate                      : 15.000 FPS

> I was hoping to use VBR rather than CBR but can't find a way to set
> it.

Looking at the Pi V4L2 controls it appears to support VBR, but ffmpeg
must set the correct values.  A quick Google says to use -q:v instead
of -b:v, e.g. https://slhck.info/video/2017/02/24/vbr-settings.html

I'm streaming off the Pi camera in variable framerate mode (at max 15
fps), so I'm trying to get frames duplicated as necessary to maintain a
fixed 15 fps on the output.

I was using the `-r` option for this to set the output framerate so
possibly adding this might help, as it doesn't look like you're telling
ffmpeg what output framerate to use.  Possibly if the input file is VFR
it might be carrying that flag across.

I am also using this option to try to fix up the timestamps:

  -bsf "setts=ts=N*(1/${FPS})*100000,h264_metadata=tick_rate=$[$FPS * 2]"

However this doesn't seem to be working right and appears to be what is
marking the output as 13.5 fps instead of 15 fps.  So if anyone knows
what is wrong with my calculations please let me know.

Unfortunately this doesn't work too well for streaming as ffplay likes
to keep a 10-15 second buffer so the streamed video has an enormous
delay. I suspect it's something to do with these timestamps as the
instant I stop streaming, ffplay suddenly rushes through the 10 second
buffer at 60 fps.  I just wish I could figure out how to tell ffplay
not to buffer quite so much video!

I have tried various combinations of -sync ext -fflags nobuffer -flags
low_delay -strict experimental -vf setpts=N/40/TB -an -fast
-noframedrop -probesize 32 but none of them make much difference which
is what leads me to think the issue might be on the encoding side.

Cheers,
Adam.