Investigate and fix frames dropping issues in videocapture found in ses-20240830

[vmdocua]

This PR is brother of issue #68 we have with frames dropping. Got this issue in ReproNim ses-20240830 time calibration session. Closes #112. Closes #113. Closes #114.

Proposal is listed below:

• Specify non-default H.264 configuration with less resources consuming like CPU, play with CRF, and other CPU/GPU built-in features. Note: in future also consider QSV (Quick Sync Video) features.
• Fix video duration issue. Mkv container has both video and audio streams and looks like they are not synced well.
• Auto-recovery of ffmpeg process in reprostim-videocapture utility #114 .
• upon reloading config file prior main log file got overwritten #112 - (found when updating configuration @ reproiner).
• optionally wrap executions of ffmpeg with duct #113 .

Re-configure reprostim-videocapture/ffmpeg with options:

• v_enc:

  • -preset ultrafast - fastest encoding, lowest compression efficiency.
  • -crf 18 - consider CRF value 17 or 18 to be visually lossless or nearly.
  • -tune zerolatency - reduce latency during encoding, to improove timing in recorded videos.
  • -b:v 2M - cut video bitrate to 2 Mbps (this rate can be changed later).
  • -maxrate 2M - set the same as plain bitrate, and don't allow encoder to exceed it even temporarily.
  • -bufsize 4M - hardcode video buffer size to 4 Mbps.
  • -vf setpts=PTS-STARTPTS - apply filter to reset the timestamps of the video frames, starting from 0. ?? Consider in future explict frame rate specification via -r *** option like 60 FPS.

• n_threads:

  • -threads 4 - force ffmpeg to use only 4 CPU/threads explicitly. Consider in furture 2 or 3 values according to reproiner box hardware (it's 4 core box by now).

• a_enc:

  • -af asetpts=PTS-STARTPTS - apply filter to reset the timestamps of the audio frames, starting from 0. ?? Consider in future explicit -ar *** sample rate values extracted from ALSA/Magewell (44.1K, 48K etc) to improove timing and synchronization with video stream.

Current results of applied options on dev PC:

1. Linux OOM doesn't kill ffmpeg anymore after 1-2 minutes of video capture.
2. Video and audio streams are almost in sync in recorded video file, but it's possible some small deviations still exists.
3. CPU usage should be reduced in 2+ times.
4. Visually don't see video quality lost, but it's possible on real system we will need still to increase it.
5. Increased *.mkv file size. For test was used video from calibration session we have, resolution 1920x1080, 60 FPS. Video length 10 minutes, video file size is 100MB, so this corresponds to 10MB/minute, 0.6GB /hour, 14.4GB /day or 430GB /month.

Current results of applied options @reproiner:

1. Bad picture quality for dynamic videos, sports etc. It's possible that we need to increase bitrate from 2M close to standard quality for 1080p 60fps H.264 like 8-12Mbps. e.g -b:v 8M -maxrate 8M -bufsize 16M and monitor CPU, *.mkv size and quality.