Stream from (cheap) camera unstable at higher bitrate?

[pyspilf]

I submit this to the collective wisdom here, as it doesn't make much sense to me... I would assume that a higher bitrate setting on a camera implies less compression and therefore less processor load on the camera side.

This test I ran on some cheap cameras, I have not tried the same on my Dahua/Hikvision cameras, so if you consider this could be the root cause, then it would also be good to know.

1. 2x 5mp cameras running over a Ubiquiti radio link (only 20 meters, signal is very good, link is being used at around 15-20Mbps, so nowhere near capacity and latency is low on such a short link)
2. Cameras running at 15fps, H264 VBR 5120kbps -> stable
3. Instability in the framerate in BI, varying wildly between 5-6fps to 15-16fps under these conditions when:
(a) change VBR to CBR and keep 5120kbps
(b) change VBR to CBR and increase rate to 6144kbps or 8192kbps
(c) keep VBR and increase rate to 6144kbpx or 8192kbps

While testing (a) (b) and (c) above I was monitoring the Ubiquiti link and the usage was still at the same 15-20Mbps, so it seemed like the camera was not really outputting that much more data...

On the BI side, CPU usage at around 15% with many other cameras running, and network at around 80-90Mbps (it is a gigabit connection)

So I can't see bottlenecks on the network or BI components...

Is it a known fact that issues with cheap cameras can be seen also in not being stable at higher bitrates? Did I happen to find the sweet spot for mine running at 15fps H264 VBR 5120kbps??

I am quite puzzled...

Thanks

 

[wittaj]

Keep in mind that these type of cameras, although are spec'd and capable of these various parameters, real world testing by many of us shows if you try to run these units at higher FPS and higher bitrates than needed that you will max out the CPU in the unit and then it bugs out just long enough that you miss something or video is choppy or pixelated or you get lost signals. My car is rated for 6,000RPM redline, but I am not gonna run it in 3rd gear on the highway at 6,000RPM...same with these types of units - gotta keep them under rated capacity. Some may do better than others, but trying to use the rated "spec" of every option available is usually not going to work well, either with a car or a camera or NVR.

I'm not saying my analogy of a car redline or MPG is a perfect analogy, but rather I am pointing out a fact that stuff we buy is always marketed as more capable than it is, especially if you are using all of the features. Does your car get its stated MPG in every situation - NO...

Can a little 4 cylinder base model Ford go up an interstate incline of 4% with the air conditioning at full blast at the speed limit - NO. I remember growing up we would have to turn off the AC going up big hills LOL. We called it turbo boost LOL.



Do we really believe every marketing claim of every product we see on Amazon?

Just like a computer - it is rated for this and that, but if you are running the CPU at 100%, something is going to give. Same with these little cameras with a lot less computing power.

So a few of my cams have a system status screen, and they call it a CPU, so that is why I am calling it a CPU, but this shows this camera running at 8192 bitrate, H264, CBR, and 12 FPS is hitting the camera processor at 47% and jumps to 70% with motion. If I up the camera to 30 FPS, the usage is in the high 90% range, but then with motion, it maxes out and would get unstable.

Or if I keep it at 12 FPS and use the camera motion detection, the CPU in the camera goes to 60% idle.

This would be nice if all cams had this so we could see how our settings impact the performance of the camera. I think running these cams close to capacity is probably harder to overcome than a computer spike at 100% CPU.

So who knows with a cheapo cam - maybe higher bitrate is the limiting factor that stalls it out.

 

[pyspilf]

Many thanks for your comprehensive and fast response - totally aligned with you. I just thought that increasing the bitrate while leaving the framerate lowish would actually improve performance on the camera side, but of course I do not know the details of the components used and their ratings, and quality... it would seem, in this case, anything above 5120kbps the camera dislikes LOL

I wish I had a kind of status screen like what you show at the bottom.

PS - I haven't even dared to enable any motion or any other feature on these cameras, just plain main and substreams.