-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Make changing the bitrate on an rpiCamera stream a fast operation #2703
Comments
Hello, thanks for reporting this missing feature, after some investigation it turned out that V4L2 allows to change the bitrate and IDR period of a running encoder. The server already have a hot reloading feature that allows to reload parameters through the API or by changing the configuration file, thus it was easy to link the two things together. This is implemented in #2764, you can find a nightly release here (click on "artifacts", "binaries"): https://github.com/bluenviron/mediamtx/actions/runs/7052003567 |
@aler9 awesome, thanks very much! Now I only need to decide if I want to put the nightly into our release :) |
This issue is mentioned in release v1.4.0 🚀 |
This issue is being locked automatically because it has been closed for more than 6 months. |
Describe the feature
Previously, we were using the 0.22 version of mediamtx connected to v4l2rtspserver and the legacy RPI camera stack to deliver a WebRTC stream. Using this allowed one to change the bitrate (via V4L2) of a running stream, and if the stream required a restart it was pretty fast to pick it up again. It looks like this:
(remote camera - v4l2rtspserver) <-> router (mediamtx)
We've now switched to using MediaMTX 1.3 and this setup:
(remote camera - mediamtx) <-> router (mediamtx)
Now, if you mutate the bitrate of an rpiCamera stream via the API the WebRTC stream provided by the router the image freezes and takes some time to disconnect/reconnect. Likewise, if you connect to the stream via VLC it breaks and you have to reconnect. So it would be great if changing the bitrate didn't break the stream at all (maybe this is not technically possible with libcamera?). I've also raised the slow frontend WebRTC reconnect separately in #2718
The text was updated successfully, but these errors were encountered: