~1 second delay when using Lossless image compression and Device Link Throughput Limit
Answered
I am observing the following in Spinview with a Blackfly Gige 5MP color camera.
- Lossless compression ON, Device Link Throughput Limit = 125,000,000. Low delay.
- Lossless compression ON, Device Link Throughput Limit = 60,000,000. About 1 second delay.
- Lossless compression OFF, Device Link Throughput Limit = 60,000,000. Low delay.
The delay was estimated by waving my hand up and down in front of the camera. I've set the stream buffer handling mode to NewestOnly. My hope was scenario 2 would also have a low delay.
Any suggestions?
-
Official comment
Hello Nghia,
We looked at this further and found a better solution and the real root cause for this delay.
When you have compression enabled, there are 2 modes the camera can be in:
1. If your Acqusition Framerate is enabled, you are specifying the target framerate you want. This results in the Compression Saturation Priority being in DropFrames mode, because it will drop frames if the datarate is saturated.
2. If your Acqusition Framerate is disabled, the cameras fps will vary depending on the scene. This changes the Compression Saturation Priority to Reduce Framerate, because it will adjust the framerate to match the maximum achievable datarate.
Regardless of which mode you are using, when you choose to decrease your Device Link Throughput Limit, your data rate is lower than what the compression algorithm requests. The compression algorithm uses another property (Max Datarate Threshold) to determine the maximum desired datarate for the compressed stream.
This property should mirror the DeviceLinkThroughput Limit, but it doesn't seem to. The delay you are seeing is because your DeviceLinkThroughput limit is lower than the datarate the compression algorithm is targeting.
You can resolve your delay issue by adjusting Max Datarate Threshold to match Device Link Throughput Limit.
Doing so will sync these values up and you will no longer drop frames, so the delay is gone.
We will raise an internal ticket to fix this, but it would take a while for any such changes to get pushed through to production and shipping firmware, so adjusting the extra property above is your best solution.
Thank you,
Demos
-
Hello Nghia,
Thank you for the post. I can see the same thing here. I will look into this to see if we can explain the reason, or if it is something we need to fix.
Thank you,
Demos
0 -
Hello Nghia, I found that this delay only occured when the framerate I set on the camera was higher than the max rate the camera can do with compression enabled. If I dropped the framerate to a number less than the resulting framerate, the delay went away.
I believe what is happening is:
When compression is off, changing the devicelinkthroughput limit will change the max framerate (24fps at 125MBps, 11.5fps at 60MBps)
With compression on, because the framerate is variable depending on the scene, we do not vary the maximum framerate (33fps). This is fine when you are running at full bandwidth, but when you decrease the bandwidth and the camera is now running faster than possible, you are dropping and buffering frames which causes the delay.
I believe this can be resolved on our side if we decreased the max framerate when reducing devicelinkthroughput limit while in compression. I will raise a ticket, but in the meantime, can you just set your framerate lower to match your compressed framerate, assuming you are limiting your bandwidth to run multiple cameras?
Thank you,
Demos
0 -
Thanks! This appears to solve the problem.
0
Please sign in to leave a comment.
Comments
4 comments