Custom driver we developed keep on giving "video stream in overflow" error

MIP
, , , ,
1

I keep on getting the below when passing the camera feed via H264 to XProtect as a MIP Driver.

2025-04-03 08:53:56.886+02:00 [ 70] WARNING - f8ffb3e1-0370-44b4-85b6-83b0683c0024 Yulong 2 Pipeline YulongDT video stream in overflow. QueueCount=200, BytesInQueue=4327670

This happens after a while only, and the timing varies. The stream is of a 20fps H264 type.

The feed shows up on a local Smart Client if opened, but not on a remote networked one. The feed records while it is not in overflow and I can playback it, once again, on the local Smart Client but not on the remote Smart Client.

The local Smart Client can also export footage correctly, while the remote Smart Client cannot.

Other cameras on the system work as expected, so it seems to be a problem with the driver itself that we developed.

What could cause these issues?

I have checked the CPU use, the feed rates, the timestamps of the frames, the harddrive usage level, replaced the magnetic drive with an SSD just in case it would help, and a few other things.

Help?

Kind regards,

Peter Peiser

Edit:

Testing on Milestone 2025 R1 Corporate Test

I have managed to grab diagnostic information from the Smart Client. It simultaneously overflows and underflows?

Screenshot from 2025-04-03 15-22-10
Screenshot from 2025-04-03 15-22-10190×221 43.1 KB
Edit 2:

It seems there’s a lot of interframe jitter, so I smoothed it out a bit, without much luck

Edit 3:

I see the Recording Server CPU bursts really high when this feed starts, which is a high-ish movement H264 stream. Also the Smart Client on the remote machine which does not work does not have hardware acceleration. The recording server has hardware acceleration on which the Smart Client works. Switching off hardware acceleration seems to stop the server from decoding the stream completely for some reason.

Edit 4:

Removing motion sensing from the camera fixed the Recording Server CPU spikes.

Edit 5:

The video (after the above) decodes on any machine with hardware decoding, but shows nothing where there is no hardware decoding.

2

We suggest that you try to log whenever a frame is sent and evaluate if this is done at fairly regular interval or might be the source of a bursting effect.

3

Thanks for the feedback! The frames have a small burst effect, but I have smoothed it out via buffering and delaying frame relay to the Recording Server. The last issue I have is that the stream doesn’t seem to decode on non-accelerated client machines. The rest of the issues seem sorted now after lots of effort here.

Technically the latest issue is the only one, that the Smart Client doesn’t want to decode the stream if there is no hardware acceleration. Should I file an additional post for that?

4

Yes, please. Please do a new post..

Include description of the setup where it fails. Do you test with the same PC enabling and disabling hardware acceleration in turns, or do you have a special test pc with no hardware acceleration capabilities?

Please include also a small export in Milestone format.

Tip for testing with the same PC - https://developer.milestonesys.com/s/question/0D5bH000015gUb0SAE/sdk-2423-changing-hardwaredecodingmode-does-not-work-for-imageviewercontrol

5

I added a new post for the new problem as requested, thanks! Will continue interacting on that post.