I am being “called out” by a commenter on a different site. I am “duping” users, and I might not know what I am talking about (buyers beware!).
The commenter claims that JPEG (or MxPEG) is the superior choice for video surveillance. Having observed poor video that had been compressed with MPEG (and I use the term MPEG for all variants here – including H.264 and HEVC) is of poor quality, the logical conclusion is that MPEG is bad, and JPEG is good (because it doesn’t compress as much).
The discussion reminds me of discussions I’ve had with HDcctv proponents. Evangelists that get up on a pedestal never like it when someone questions their authority. Sure, I understand that being told that you are factually wrong is not fun, and I am all too well aware of the Dunning-Kruger and the backfire effect, and so I’ve chosen not to pursue the discussion any further in that forum. A forum is a bad place to discuss politics and religion, but it’s a horrible place to discuss facts, so why even bother?
There’s an old joke about a CEO, a physicist and an engineer stranded on an island (substitute the CEO for whatever you like). A can of spam drifts ashore, and the three discuss how to open it and share the contents. The physicist suggest that they heat the can, thereby making the contents expand and break the can. The engineer suggest using a sharp rock, but then the CEO interrupts by saying “let’s assume that we have a can-opener…”
A variant of the joke would be this: An internet commenter, a customer and Morten (me) are sitting in a store. The customer says, I have $2000, I need 7 days retention, 8 fps, and I have 16 cameras. Morten says, “well, if you use MPEG, you will be able to record your cameras for 7 days at 8 fps. The quality will not be great, but at least you will have something”. Then the commenter says “Let’s assume that you only needed 1 day retention, or that you only had 2 cameras, or perhaps we can pretend you have $5000 to spend”.
Some of the most hysterical people, when it comes to video quality, are the good people of Hollywood. One of the “low-cost” companies is RED. They have a proprietary codec based on JPEG2000, offering a lossy compression of 1:3. But keep in mind that an uncompressed 4K frame clocks in at 24 MB (assuming 8 bit 4:4:4 YCrCb ), so at 3:1 compression, you’d still need to store 8 MB per frame. Sure, 1080p is only 1/4th of that, but it’s still a hell of a lot of data.
How many customers will be able/willing to afford that kind of bandwidth requirement? Not many. Perhaps zero.
10 years ago, the commenter “published” a document, in which he thanks the members of the MPEG group (MPEG stands for Moving Picture Experts Group), yet the reference list simply points to “MPEG committee various published documents”. If I handed in a paper that had that sort of reference, I think I would have flunked the course. But this is the Internet, you can “publish” any kind of garbage you want. Usually, when you make a scientific publication it is peer-reviewed, I don’t know what peers reviewed this nonsense.
For example, the author states that
MPEG/H264 codecs are considered a lossy compression method. You will have no doubt seen the effects of MPEG compression in everyday life when watching normal digital television, for example sports coverage or live event coverage when the bandwidth available is restricted the image sometimes pixelates into blocks and then gradually recovers as a new key frame is transmitted.
The logical conclusion from this is that there would be that a) JPEG isn’t lossy (which it most definitely is) or that b) you would not see blockiness if broadcasters used JPEG (which you most definitely would).
I suppose that I should try to explain why removing temporal redundancy will always lead to better compression. Or, of you keep the bandwidth constant, MPEG will in 99.9% of all cases deliver better quality. Or trying to explain that JPEG also uses macroblocks and also decimates the frequency components prior to huffman-encoding. I won’t. It’s pointless, when you are clinging to an idea for 10 years, no amount of proof will sway you.
The cost of making MPEG more efficient is CPU cycles. Encoding efficiently requires more memory and more CPU cycles per frame. You could argue that the cost in CPU cycles is not worth the extra compression, but that’s not what the commenter argues. No, the commenter argues that JPEG/MxPEG is a better choice for video surveillance than MPEG – period. And that’s just bollocks.
JPEG has some advantages to MPEG, primarily that it is universally supported in web-browsers, offers direct random access to each frame and there are no patent gang (MPEGLA) to deal with. But none of those arguments deal with compression efficiency. The primary problem with JPEG for video is that the temporal redundancy is not removed. MPEG allows you to do the same, but it would be stupid to do so. Throwing away redundant information is a good thing. You can then claim that some people/integrators/systems throw away things that are not redundant, like facial features, license plates and so on, but that sure as hell has nothing to do with the codec itself.
MxPEG tries to get rid of redundant temporal information too. By doing a delta, and sending only the macroblocks that did change, it gets better compression than JPEG. Either you get a full macroblock, or you get nothing. Practically it does this by inserting a comment in the EXIF header that describes what blocks have changed compared to the previous frame. But MxPEG is not natively supported by any web-browsers (if you know, tell me). Since there’s no use of motion-vectors, the compression is lower than MPEG (assuming constant quality). MxPEG does not offer random frame access either, which would have been a big advantage to Mobotix.
Here’s a quick synthetic test I did (JPEG fans will be quick to point out that rarely do we record screens that just show the time, but I urge anyone to perform the same test using their own equipment).
At 600 kbps the JPEG stream looked like this :
In contrast, the terrible H.264 looked better :
I deliberately did not try to capture right at an I-frame, but went for something that would show some of the damaging blocking and place it side-by-side to the JPEG frame.
It’s important to stress that this is at the same bandwidth, but also that this test was made in just 10 minutes. If you can make a side by side comparison of JPEG and H.264 at the same bandwidth, where JPEG comes out on top, I sure as shit would like to see it. It certainly will not be a common scenario.
I’ll leave it to the reader to decide if JPEG is the better choice.