Video compression matters!

iwanttosee

iwanttosee

Getting comfortable
Dec 27, 2020
510
568
US
On my Axis Q1785-LE Camera, set compression at 0%, 10%, 30%, and 50%. You can clearly see the difference in bitrate.


0% compression
1791214451515.png

10% compression
1791214514831.png

30% compression
1791214626789.png

50% compression
1791214724107.png




I have Axis, Uniview Cameras, SV3C and Hikvision cameras and they all support video compression, but they might be under a different name like image quality and/or bitrate.

Why does lower bit rate matter?
Lower bit rate allow your system to reduce CPU cycles, more footage for the same storage, reduce frame lost, reduce skip frame, reduce network traffic and more.
 
  • Like
Reactions: bp2008, mat200 and VorlonFrog
  • Like
Reactions: bigredfish and bp2008
Based on your screenshot, 50% compression is yielding approximately 1.5 Mbps bit rate. That is about as low as I would go for a 1080p @ 10 FPS stream and even then, only if you were going to be recording it continuously. Because the quality will be substantially worse in the fine details with that low of a bit rate. You don't see it as much in a still image but when something moves (especially something big) it will have more blur or blocky artifacts.

Since that is clearly either a PTZ or an LPR camera, I would recommend increasing the bit rate to at least 4 Mbps (500 kB/s should show in Blue Iris). Higher quality should help read plates that are dirty or poorly lit where the contrast is not very good.

What I really prefer to do is set up Blue Iris to record "Continuous sub + Triggered", and then I set up the sub stream at relatively low bit rate and main stream relatively high.

1791222864763.png


1791222826013.png


That way I'm recording at a piddly 0.5 Mbps most of the time, and 4-10 Mbps only when there is motion.

I try to keep sub streams around 256 to 768 Kbps (depending on the cam). Converted to kB/s as you would see in Blue Iris, that is a range of 32 to 96 kB/s.
 
Last edited:
  • Like
Reactions: OD1, Techie007L, looney2ns and 2 others
Generally the "blocking" effect of too-low-bitrate only shows up when there is movement - in a static scene there is not much difference between each frame, so the compression algorithm hardly has to transfer any data anyway.
Before getting too sold on it, wait until a vehicle drives by at decent speed, or if a PTZ, swing her around a bit and try watch the quality as its moving.

I usually go higher than I need, I prefer to be on that side of the "spectrum". However there would certainly be scenarios where the very best quality is simply not needed in which case buffing up the compression can save a huge amount of disk etc!
 
  • Like
Reactions: bigredfish and mat200
mat200 said:
Movement, also check movement and text / license plate sized text
Click to expand...

bp2008 said:
Based on your screenshot, 50% compression is yielding approximately 1.5 Mbps bit rate. That is about as low as I would go for a 1080p @ 10 FPS stream and even then, only if you were going to be recording it continuously. Because the quality will be substantially worse in the fine details with that low of a bit rate. You don't see it as much in a still image but when something moves (especially something big) it will have more blur or blocky artifacts.

Since that is clearly either a PTZ or an LPR camera, I would recommend increasing the bit rate to at least 4 Mbps (500 kB/s should show in Blue Iris). Higher quality should help read plates that are dirty or poorly lit where the contrast is not very good.

What I really prefer to do is set up Blue Iris to record "Continuous sub + Triggered", and then I set up the sub stream at relatively low bit rate and main stream relatively high.

View attachment 249975


View attachment 249974


That way I'm recording at a piddly 0.5 Mbps most of the time, and 4-10 Mbps only when there is motion.

I try to keep sub streams around 256 to 768 Kbps (depending on the cam). Converted to kB/s as you would see in Blue Iris, that is a range of 32 to 96 kB/s.
Click to expand...

looney2ns said:
Still images prove nothing. You need to compare bit rates with Video recording with movement in the scene.
Click to expand...

EagleEye7 said:
Generally the "blocking" effect of too-low-bitrate only shows up when there is movement - in a static scene there is not much difference between each frame, so the compression algorithm hardly has to transfer any data anyway.
Before getting too sold on it, wait until a vehicle drives by at decent speed, or if a PTZ, swing her around a bit and try watch the quality as its moving.

I usually go higher than I need, I prefer to be on that side of the "spectrum". However there would certainly be scenarios where the very best quality is simply not needed in which case buffing up the compression can save a huge amount of disk etc!
Click to expand...

This is an LPR camera. I added the camera twice to BI, one at 0 compression and also at 50% compression for comparison.
Happy to gather the data and report back maybe tomorrow so I can give you all both night and day pictures.

1791227097778.png
 
  • Like
Reactions: TonyR and bigredfish
  • Like
Reactions: looney2ns
Oh, ok
Then why did you ask?
 
bigredfish said:
Oh, ok
Then why did you ask?
Click to expand...
Both questions were asked and answered with words and the other one with a picture.

People weren't happy with the one still picture so I am making more picture with ALPR as proof that 50% compression on my camera can pick up license plate number just fine.

I am also discovering that the camera with no compression is leading to drop frames.

1791236362262.png
 
I was trying to be helpful, not just for you but others who stumble onto this thread with similar questions.






You edited so I'll edit
 
Last edited:
I think Codec plays a part as well, and not just the obvious compression naming scheme of h264 etc. Unfortunately you as end user have no control over the parameters.

When I look at the picture from my 4k cameras running even at max bit rate of around 18mbs from memory, there a lot of compression and discarded info in the background which makes me believe the CODEC is programmed to discard a lot of non central or background information. Whether this is true or not, I don't know. However, it's the only explanation I can think of for backgrounds that lack detail, leaves that aren't leaves but blotches and the inability to zoom even moderately into an 8mb (4k) picture without significant loss of sharpness, pixel noise. I'm sure pictures on my phone when it had a similar size sensor a few years ago never had these limitations albeit the phone could use much larger bit rates. That said, 18mbs is not insignificant. I'm guessing the problem is the codec is probably set up to discard info to maintain a decent picture on low bit rates. Info that isn't not discarded when bit rates are increased. Just guesswork though.

If the guess is correct, it shows an industry still set up to use minimum space rather than offer the end user a choice of space vs quality.

However, no different really from the current apparent choices for hardware which seem to be for smaller cheaper sensors & AI enhancement instead of larger better sensors & better picture quality through the primary part of the chain. I always remember what I was told with Hifi - what you get out is limited by what you put in. In other words, no matter how good the quality of components downstream, if the source isn't high quality, what you get out won't be either.
 
  • Like
Reactions: bigredfish
You must log in or register to reply here.
Top Bottom