Milestone SDK’s RawLiveSource is used to retrieve raw H.264 video frames from cameras and forward them to RTSP/WebRTC Server using FFmpeg for RTSP and WebRTC streaming. This was working correctly for months on multiple Milestone environments. Suddenly, without any SDK or application changes, WebRTC streaming stopped working, while RTSP continues to work fine. After investigating, suspect a change in the profile or encoding of the H.264 video frames returned by RawLiveSource.
SDK Version:
MilestoneSystems.VideoOS.Platform.SDK NuGet package, version 25.1.3
Kindly request your support on the following queries:
Was there any global update or change in how RawLiveSource delivers video frames?
There are consistent breakage across multiple sites, which was working fine previously (around 3 weeks before)
Is there any supported method to force RawLiveSource to return H.264 video in Baseline profile (no B-frames)?
This is critical for WebRTC clients that require strict compatibility.
Are there any recommended practices or SDK configurations when forwarding raw H.264 frames to an external WebRTC server (without re-encoding)?
Appreciate any insights or support from the SDK team. Thanks.
Q. Was there any global update or change in how RawLiveSource delivers video frames?
A. Aside from bug fixes, there have been no changes in how H.264 data is delivered through RawLiveSource between the previous version and 25R1.
Q. Is there any supported method to force RawLiveSource to return H.264 video in Baseline profile (no B-frames)?
A. There is no way to do this (without transcoding the stream yourself), as RawLiveSource simply delivers the raw video as received by the Recording Server.
Q. Are there any recommended practices or SDK configurations when forwarding raw H.264 frames to an external WebRTC server (without re-encoding)?
A. It is possible, while cumbersome, to retrieve a video GOP and determine the appropriate profile, and then deliver the correct profile information as part of your OfferSDP when establishing the WebRTC connection. We do not currently recommend any specific course of action for this, however.
Have you tried this with different cameras, or just a single one?
Is it possible there has been a firmware update in your cameras that has altered the data being sent?
One option would be to try with two separate systems, one running the previously working version, and one running the new, and dumping the output of RawLiveSource to files to compare.
The issue is occurring with all cameras in our lab as well as across other Milestone VMS sites. None of them are currently working with WebRTC streaming when using RawLiveSource video frames, although RTSP streaming remains functional.
This issue is not tied to a specific SDK version. While SDK version 25R1 is being used, also tested with older versions of the Milestone VideoOS.Platform SDK, and the same behavior is observed.
At this point, no version, including those that previously worked, is able to stream via WebRTC using RawLiveSource without re-encoding.
Regarding the possibility of camera firmware updates:
The same cameras in our local lab, when connected to other VMS systems (e.g., Avigilon), are still delivering WebRTC-compatible H.264 frames through SDK-based streaming.
This suggests the issue may not be related to camera firmware, and would appreciate any insights into whether there might be changes or configurations at the Recording Server or SDK level that could influence how H.264 frames are handled or exposed via RawLiveSource.
No update has been made to the VMS version in the affected environments.
Milestone VMS 2023 R1 is the VMS version, and WebRTC streaming via RawLiveSource video frames was functioning correctly earlier with this version.
Tried on a system running Milestone VMS 2025 R2, but same issue is observed there as well.
Trying to understand whether there have been any recent changes in how the Recording Server or VMS environment handles or exposes H.264 video streams via RawLiveSource, particularly aspects that could affect WebRTC compatibility, such as changes in H.264 profile, use of B-frames, or frame ordering.
Also, the same cameras, when connected to other VMS platforms (e.g., Avigilon), still provide WebRTC-compatible H.264 frames through SDK-based streaming. This suggests the issue may not be directly related to camera firmware.
Any guidance or suggestions for further diagnostics would be greatly appreciated. Thank you again for your support.
In order for there to be a change in the output from RawLiveSource, one or more of the following things would have to have happened:
1. Either the hardware settings or device settings on the camera have changed - To my mind, this seems the most immediately likely reason, were any changes to the camera settings made in the Management Client? Have you tried using different camera settings to see if there are any differences? It is possible there is simply e.g. some profile or frame rate settings that can be altered to make this work as expected.
2. The camera hardware or firmware has changed somehow - This is disproved by the fact that there are no changes in output from an alternate VMS platform.
3. The DevicePack has been updated - What version of the DevicePack is installed? Has this been updated?
4. The VMS has been changed - You mention that you are using 23R1, did you apply any new patches?
5. The SDK version has been changed - Again, this is disproved by the fact that older versions of the SDK exhibit the same behavior.
If none of the above things have changed, then the output also would not change. Are you able to run any system in a state where it works, for comparison?
Without knowing exactly what change has caused the output to be altered, it is impossible to identify what the problem is.
We would like to share a recent additional observation that may help narrow this down:
Across multiple independent Milestone sites, the issue started occurring at the same point in time.
Up until 27-Jan-2026 06:08:51 PM (Qatar Time), both RawLiveSource and RawVideoSource were delivering WebRTC-compatible H.264 frames, and WebRTC streaming was functioning correctly.
Immediately after that timestamp, WebRTC streaming stopped working correctly when using the raw frames directly. From that point onward, we have been required to transcode the stream in order to make WebRTC streaming properly.
We are also able to validate this behavior using archived/recorded video on multiple independent Milestone sites on multiple client environments:
For recorded video before 27-Jan-2026 06:08:51 PM, WebRTC streaming works correctly when using RawLiveSource/RawVideoSource frames.
For recorded video after 27-Jan-2026 06:08:51 PM, WebRTC streaming no longer works unless we transcode.
This confirms that the change is reflected directly in the stored video data itself, not only in live streaming.
Since this behavior appeared simultaneously across multiple sites, it seems less likely to be an isolated camera configuration change. We are therefore trying to understand whether there could have been:
Any background component update (e.g., Recording Server service behavior or codec handling)
Any automatic DevicePack update
Any known issue around that timeframe affecting H.264 stream characteristics exposed through RawLiveSource
Milestone XProtect does not have the capability today to do background updating. It is a feature that has been discussed as a future enhancement, but it is only future plans.
If the XProtect recording server is updated then it is not the result of an automatic background job, it can only be somebody running a recording server installer or patch installer. Same for the device pack, only by running the device pack installer is the device pack upgraded.
What you describe does not fit any known issue with MIP SDK RawLiveSource.