Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add frame rate support to mjpeg for ffmpeg compatibility #1509

Open
markfrancisonly opened this issue Dec 15, 2024 · 3 comments
Open

Add frame rate support to mjpeg for ffmpeg compatibility #1509

markfrancisonly opened this issue Dec 15, 2024 · 3 comments
Labels
question Further information is requested

Comments

@markfrancisonly
Copy link

Conversion from mjpeg to another format (h264) via ffmpeg generates invalid output.

By default, ffmpeg consumes http sources at 25 fps, unless otherwise specified. It is possible to change the ffmpeg frame rate input parameter inside go2rtc.

For instance, ffmpeg shall consume an http source at 15 fps using -r 15 input parameter:

go2rtc:
  ffmpeg:
    15_fps: -r 15 -fflags nobuffer -flags low_delay -i {input}

  streams:
    camera:
      - ffmpeg:http://127.0.0.1:1984/api/stream.mjpeg?src=camera#input=15_fps#video=h264#hardware

however, the ffmpeg input source must also emit frames at the same rate, or there will be a problem in the output: #246 (comment)

The frame mismatch issue can be correcting by emitting an precise fps from the mjpeg api to match the ffmpeg input.

Ideally, the mjpeg api would have a configurable fps via url parameter, however, if the mjpeg component is updated to emit exactly 25 fps, no configuration is required to consume the mjpeg stream from ffmpeg

@markfrancisonly markfrancisonly changed the title Add frame rate support mjpeg for ffmpeg compatibility Add frame rate support to mjpeg for ffmpeg compatibility Dec 15, 2024
@AlexxIT AlexxIT added the question Further information is requested label Dec 16, 2024
@AlexxIT
Copy link
Owner

AlexxIT commented Dec 16, 2024

Where you get info about 25 frames? I don't think HTTP has to output any particular number of frames. It's just a transport. It can use any format inside.

go2rtc can't change frame rate. It doesn't make sense. And it's not going to be accurate enough. This needs to be played with a real time clock. Sending the same shot multiple times. Which is insane for MJPEG format.

@markfrancisonly
Copy link
Author

Yes, I agree. By default, FFmpeg expects an MJPEG source to run at 25 fps unless specified otherwise. I've successfully started recording HTTP images in Frigate by pointing go2rtc to a custom MJPEG server application that streams at the exact desired fps.

The MJPEG server decouples the fetch loop from the streaming loop by:

  1. Fetch Loop: Runs at a configurable fps and saves frames to shared memory.
  2. Streaming Loop: Each consumer opens its own streaming loop with a separate, decoupled fps.

As you correctly pointed out:

  • If the stream fps is higher than the fetch fps, duplicate frames are returned.
  • If the stream fps is lower, the server provides the next frame, ensuring the stream frame rate remains precise.

This approach keeps FFmpeg satisfied and ensures that Frigate recordings are stable and reliable.

I'll create a repository shortly.

@markfrancisonly
Copy link
Author

I don't have an official reference, but you can find the ffmpeg frame rate defaults to 25 fps here:
https://github.com/search?q=repo%3AFFmpeg%2FFFmpeg+.str+%3D+%5C%2225%5C%22&type=code&p=1

I found another solution to fix the ffmpeg frame rate output in frigate,

go2rtc:
  ffmpeg:
    mjpeg: "-y -f mjpeg -use_wallclock_as_timestamps 1 -i {input}"
  streams:
    kitchen_wallpanel:
      - http://fully-kiosk:2323/?cmd=getCamshot&password=secret
      - ffmpeg:http://127.0.0.1:1984/api/stream.mjpeg?src=kitchen_wallpanel#input=mjpeg#video=h264#hardware

some HTTP input sources should be rate limited, however the config above appears to fix the frame timing issue recording the built-in mjpeg stream api from frigate. Still, a configurable http polling interval would be preferrable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants