Hi everyone,
I’m currently working on integrating video streams from Milestone XProtect into a JavaScript web application using WebRTC. I’ve been following the example provided in the Milestone Systems GitHub repository.
The integration works perfectly in Firefox – the video playback is smooth, and I’m getting the expected frame rates. However, I’m encountering a significant issue in Chromium-based browsers, specifically Microsoft Edge and Google Chrome. Despite setting the video to 30 FPS in XProtect (using the StableFPS_T800 setting), the framerate drops to around 2 FPS in these browsers. Moreover, when I increase the setting to 60 FPS, I only get about 4 FPS in Chrome (checked using chrome://webrtc-internals/). This behavior is puzzling and significantly impacts the user experience.
Here’s what I’ve done so far to diagnose the issue:
- Tested with the Universal Driver consuming an RTMP video. The low framerate persisted, indicating the problem is not with the StableFPS.
- Checked for any known issues or limitations in the Chromium WebRTC implementation.
- Confirmed that the issue persists even with the original sample app from GitHub, ruling out problems specific to my integration.
This leads me to believe that there might be a broader issue with how Chromium browsers handle WebRTC streams from XProtect. Any advice or suggestions on how to address this framerate discrepancy would be greatly appreciated.
Thank you in advance for your help!
Testing with StableFPS I see the behavior you describe. Asking a developer here, we believe there is an issue with the videos data that we distribute with StableFPS. What your Universal driver video does I cannot guess but must suspect it could have the same properties and issue as the StableFPS video.
If I test with a regular camera I see no issue. If possible please test with a regular IP camera.
As an experiment I made my own video based on the instructions “How to make your own ..”
https://doc.developer.milestonesys.com/html/index.html?base=gettingstarted/stablefps.html&tree=tree_4.html
Now I see the full frame-rate even if I am using StableFPS.
Following your advice, I conducted tests using a regular IP camera with WebRTC, and the results were indeed satisfactory with no frame rate issues observed.
Additionally, I attempted to create a custom video based on the provided instructions for use with StableFPS. Unfortunately, this resulted in an even lower frame rate than observed with the provided StableFPS video. This outcome leads me to wonder if there are specific requirements or properties for the video container or codec that must be met to achieve the expected frame rate when streaming via WebRTC.
Given these findings, I’m curious to know if there are plans to adjust the StableFPS feature or the WebRTC implementation to address these discrepancies. Ensuring compatibility and consistent performance across different browsers is crucial for our application, and any guidance or updates on this matter would be greatly appreciated.
Thank you once again for your support and looking forward to any further advice or updates you might have.
I have a feedback from one of Milestone’s expert developers.
The issue here is b-frames. As a WebRTC client, according to the standard, you must only support VP8 and H.264 Constrained Baseline (https://datatracker.ietf.org/doc/html/rfc7742#section-5). H.264 Constrained Baseline does not have support for b-frames and therefore it goes wrong when StableFPS sends such. An easy fix, however, is simply to change the video streams in use to StableFPS so that they do not contain b-frames.