So many times I have been asked a question that says a lot about the current state of the industry:

What is the file size of the MPEG compression used by so-and-so DVR?

Well, there is no such thing as file size when talking about Video Compression.

Video compressions are all compressions that use time as one of the dimensions during the compression (the horizontal and vertical pixels being the other two dimensions).
Such compressions are MPEG1, MPEG2, MPEG4, H264, etc. They can only be expressed in kb/s or Mb/s.
Video compressions do require continuous presence of a signal, and using the time dimension, the motion prediction and GOP (Group Of Pictures) concept can produce quite an efficient compression.
A standard definition video (both in PAL and NTSC) when converted to digital stream would require around 166Mb/s per camera, if they are not compressed.
Imagine having a DVR/NVRs recording 16 cameras, for example, without using compression.
You would need 2.6 Gb/s continuous data transfer. No hardware can cope with such data traffic.

Enter the world of video compression.

It all started with MPEG1, around 1Mb/s streaming for a VHS quality (basically what we now call it CIF).
Video compression includes compression of audio as well. The popular MP3 for exampleis the audio layer of the MPEG1 video compression.

Later on, it improved with MPEG2, used widely for DVD movies, and using around 4Mb/s to give you the same quality illusion of motion picture video as the 166Mb/s. This is an impressive achievement, as it equals over 41x compression.

Yet, in CCTV, we (always) want more.

Nowadays, even 1Mb/s might be considered too much, but some video compressions (liek H264) may offer a simialr visual quality as MPEG2 at 4Mb/s.

The Image compressions, on the other hand, are the ones where you can say my file size is 20kB, 30kB or 50kB or more. “Decent” quality requires at least 40kB.
This is a compression that is applied to image pixels in two dimensions only - horizontal and vertical.
Most popular image compressions are, of course, JPEG, Wavelet and JPEG2000 (basically wavelet, but standardised).
So, if you use image compression with the “live” image rate (25 i/s for PAL, and 30 for NTSC) we would get at least 25 x 40kB = 1000kB/s = 8Mb/s.

As it can be seen, this is not as efficient as the video compression.

So why would we use it?

Well, in image compression we can multiplex signals. The compression engine “doesn’t care” which camera the next image comes from. There is no dependancy on time. And, importantly, in image compressions, the one image is self-sufficient to prove originality when exported.
The unwanted side effect of image compression is the interlace artefacts, as we capture, encode and record all images as TV fields. If an object moves quickly across the camera view, each time the object is picked up by the CCTV camera field exposure (1/50s for PAL, and 1/60s for NTSC) it would have travelled certain distance, which are seen as interlace artefacts.
This is not a problem with the compression (as thought by may), it is a “natural” result from recording a video streaming into discrete field images. Eliminating or minimising such artefacts is usually done by “de-interlacing” available on many DVRs/NVRs, or photo editing programs such as PhotoShop.

So there it is. Video and Image compressions in a nut-shell.

• BROWSE / IN TIMELINE
• « A new focus on CCTV
• » Dynamic range of solid state imaging devices

• BROWSE / IN Compression