CRITICAL: Monibuca Alters FPS from 60 FPS to 62.5 FPS

[abrar71]

Description:

I've recently run into an issue with the Monibuca streaming server while streaming a 60 FPS video file named frame_counter_4k_60fps.flv. I used the following FFmpeg command to stream the video:

ffmpeg -re -i /ramdisk/frame_counter_4k_60fps.flv -c copy -f flv rtmp://127.0.0.1/app/hello123

Input #0, flv, from '/ramdisk/frame_counter_4k_60fps.flv':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf59.16.100
  Duration: 00:01:00.04, start: 0.019000, bitrate: 658 kb/s
  Stream #0:0: Video: h264 (High), yuv420p(progressive), 3840x2160 [SAR 1:1 DAR 16:9], 640 kb/s, 60 fps, 60 tbr, 1k tbn
  Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp, 2 kb/s
Output #0, flv, to 'rtmp://127.0.0.1/app/hello123':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf60.3.100
  Stream #0:0: Video: h264 (High) ([7][0][0][0] / 0x0007), yuv420p(progressive), 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 640 kb/s, 60 fps, 60 tbr, 1k tbn
  Stream #0:1: Audio: aac (LC) ([10][0][0][0] / 0x000A), 48000 Hz, stereo, fltp, 2 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)

When I attempted to play back the RTMP stream using:

ffmpeg -i rtmp://127.0.0.1/app/hello123

 Duration: N/A, start: 0.013000, bitrate: N/A
  Stream #0:0: Video: h264 (High), yuv420p(progressive), 3840x2160 [SAR 1:1 DAR 16:9], 62.50 fps, 60 tbr, 1k tbn
  Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp

or through the HTTP MP4 URL:

http://127.0.0.1:8080/fmp4/app/hello123.mp4

I observed that the output video's frame rate was altered to 62.5 FPS.

For reference, here are some observations:

• Original 60 FPS was changed to 62.5 FPS.
• Original 29.97 FPS was altered to 30.30 FPS.
• Original 30 FPS was also altered to 30.30 FPS.

Moreover, I've also noticed that both the FPS (frames per second) and TBR (target bitrate) values are modified in the output video.

I've attached both the

• Sample input file (frame_counter_4k_60fps.flv.zip).
• Screenshot or log output from FFmpeg indicating the changed frame rate.

Expected Behaviour:
The Monibuca streaming server should retain the original frame rate and TBR values of the input video without modifying them.

Actual Behaviour:
The server changes the frame rate and TBR values during streaming.

Steps to Reproduce:

1. Stream the file frame_counter_4k_60fps.flv using the provided FFmpeg command.
2. Playback the RTMP stream using FFmpeg with the provided command.
3. Observe the altered frame rate and TBR values.

I'd appreciate any guidance or resolution on this matter.

[langhuihui]

I'll take a look. Thank u.

[langhuihui]

I found the reason, because the server will play back from the nearest keyframe position, and then when it receives the latest keyframe, it will directly jump to the latest keyframe and start playing. The value of fps displayed in ffmpeg is calculated based on the beginning, not in real-time. The real fps will not change, and the server will have other additional operations besides the previous one. You can also access /api/stream? StreamPath=app/hello123 obtains information about the stream, which includes real-time calculated fps

[abrar71]

Thank you very much for finding out the reason,
How can we fix this as its crucial FPS and TBR values remain unchanged while remuxing the stream

[langhuihui]

In fact, FPS has not changed, it is only caused by the skip frame operation at the beginning. If the skip frame operation is not performed, the playback stream will always maintain a delay time

[langhuihui]

By the way, why do you care so much about the FPS displayed in ffmpeg

[abrar71]

It is critical because that FPS is used by live encoders to determine the FPS of the output video for people who are relaying to other platforms or have their own encoders.

The standard is that the metadata like FPS and other video encoding parameters should not be modified when remuxing or relaying live streams.