We are using XProtect Professional+ 2024 R2 and WebRTC JavaScript.
When specifying Playback time in WebRTC JavaScript, we are experiencing an issue where video playback is limited to 1 fps.
If Playback time is not specified in WebRTC JavaScript, video playback works at 15 fps.
Please explain the cause of this issue and how to achieve 15 fps video playback even when specifying Playback time.
The fps value is confirmed using framesPerSecond in chrome://webrtc-internals.
Also, this issue likely did not occur about a month ago.
The only environmental changes since then are updates to the browser and OS versions (patches).
Environment information:
XProtect Professional+ 2024 R2
Windows Server 2025 (24H2)
Chrome 138.0.7204.169
Best Regards.
Supplementary information:
When playback is performed using XProtect Smart Client, it is displayed at approximately 15 fps.
We have confirmed that the same issue (where VOD is limited to 1 fps) also occurs with XProtect Professional+ 2025 R2 and WebRTC JavaScript (2025 R2).
For your reference, we tested with two versions of the browser (Chrome), 132 (2025/1) and 137 (2025/6), but the issue did not change. In other words, it is not caused by a change in the browser version.
As this matter is urgent, we would appreciate it if you could provide a response, even if it is just a progress update.
Best Regards.
I’ve conducted tests in the Milestone test labs and observed results that are consistent with or similar to your findings. I’ve now escalated the issue to Milestone Development for further investigation. I’ll provide updates here as soon as additional information becomes available.
Thank you for your reply.
If you find out the conditions under which the issue occurs and any possible workarounds, please let me know.
For example, cases where the issue does not occur in certain versions of XProtect Professional+, and so on.
Best Regards.
Hello, everyone.
We encountered a similar problem when working with Web.
We use Web Client 2023 R2 (VMS XProtect Professional Plus 2023R2).
When receiving a set of images from the specified server using mipsdkmobile-web for the corresponding server version (https://github.com/milestonesys/mipsdkmobile-web), the retrieval of archived video (in the form of a set of images) is slow (as is the case when working in the XProtect® Web Client 2023 R2 interface), while receiving live video occurs without delay.
Question: How can we configure the Milestone system so that the delivery of video archives via mipsdkmobile-web occurs without delay?
Dear Denys Malyk,
I believe this is a different issue from the one you mentioned.
In our case, the problem is that playback using XProtect WebRTC with a specified playback time is limited to 1 fps.
On the other hand, when playing back recorded video with XProtect Smart Client, it is played at 15 fps.
Also, this issue does not occur in the preview screen of XProtect Management Client.
In other words, the limitation to 1 fps occurs only when using Playback time with WebRTC.
Kouzou Matsuyama,
Thank you for your reply.
Best Regards.
This is urgent, so please let me know if you have any information, even if it’s only partial.
In particular, I would like to know the conditions under which it occurs and how to avoid it.
I would like to report on the subsequent situation.
- Until around 18:00 on 8/29, it was in a 1fps state.
- After that, I did not access the system, but when I accessed it again around 14:00 on 9/4, the issue had been resolved. All three environments where the issue had occurred (two actual machines, one AWS) were resolved.
- No particular settings were changed (although some machines were restarted).
- When playing back data from August, when the 1fps issue occurred, it still plays back at 1fps. (As mentioned before, playback with the Smart Client displays at 15fps.)
Best Regards.
Thank you for reporting this, I hope that the analysis will explain this. As I mentioned I did reproduce the behavior. Your new observations is probably a very important clue, I have sent the information on your observations to the developer that is working on on this.
I will post here what the developer found while analyzing, it is his feedback unmodified…
*
We have the same experience here. We cannot reproduce anymore. I’ve tried with the same camera as Bo. I tried to change configuration and test in different ways, but the issue have disappeared.
I’ve checked release of Chrome and found a fix that might explain this:
[crd host] Fix garbled frame stats for extrapolated frames
The frame stats is created by WebrtcVideoStream as
WebrtcVideoStream::FrameStats. However, when WebrtcVideoEncoderWrapper
creates a copy of it for extrapolated frames, it uses the copy ctor of
WebrtcVideoEncoder::FrameStats, which is missing some fields. When
WebrtcVideoStream gets back the frame stats, it down-casts it to
WebrtcVideoStream::FrameStats, which causes out-of-bound reads.
https://chromium.googlesource.com/chromium/src/+log/139.0.7258.156..140.0.7339.80?pretty=fuller&n=10000
Note there is a lot on the page. Search for “Fix garbled frame stats for extrapolated frames“ to find it.
*
Thank you for your information.
We have also reviewed the issue again on our end and looked into changing browsers.
- The 1fps issue occurred not only in Chrome, but also in Firefox.
- The recordings since September no longer have the 1fps issue, but when playing back VODs from dates when the 1fps problem occurred (August), the issue reproduces in all browsers.
Based on the above, we suspect that it is not caused solely by a Chromium bug.
If the root cause is unknown, we may continue to face the risk of recurrence in the future, so please let us know if you discover anything through your investigation.
Best Regards.
Could you please let me know if the root cause of this issue has been identified or if there has been any progress in the investigation?
While there were comments about the possibility of the following Chrome issue, since we have confirmed that this problem also occurs in Firefox, isn’t it likely caused by a different reason? We’d appreciate your comments on that point as well.
https://chromium.googlesource.com/chromium/src/+log/139.0.7258.156..140.0.7339.80?pretty=fuller&n=10000"
Best Regards.
We never found the root cause. Our analysis was only theoretically as we could not reproduce when the developer was doing his analysis. We will not pursue this issue as we assume we cannot get closer to finding a root cause as long as we cannot reproduce.
I understand the situation. Please allow me to ask a few questions.
In your recent response, when you say “it could not be reproduced when the developer was doing his analysis,” does this mean that the issue cannot be reproduced in the current environment?
Also, could you confirm whether the issue was reproduced at the time of my post on 22 August 2025 at 06:12?
Lastly, if there is any specific information that should be collected when the issue is reproduced to help with investigation, please let me know.
Best Regards.