In Defence of Mobotix

Mobotix posted an article on H.264 (h.t. John Honovich). I thought it was a good source of information describing some potential issues with H.264, I believe the concerns raised are valid and real. But, as Steve points out in his tweet, the argument is perhaps a straw-man argument as it describes issues that occur in constant bit-rate encoding, which is what broadcasters like to use (as they have a pretty fixed bandwidth budget per channel). Most cameras will allow you to pick constant quality, essentially turning each I-frame into a JPEG if there is a lot of motion (ok, a very rough approximation, but this is the internet, I can write any approximation that I want!). In that case H.264 gives you the best of both worlds. I STILL stand by my own critique of H.264 as it relates to our client πŸ™‚

If, however, you propose MJPEG as an alternative, then you should not forget the many static scenes that we see in surveillance (storage rooms, empty hallways with no motion 80% of the time and so on). In those situations it makes absolutely no sense to record a full frame with no reduction in temporal redundancy. Mobotix has a solution for this called MxPEG (if I recall correctly), which is perhaps the motive for the article?

I don’t know if people understand the purpose of the different settings, if the article helps people understand that constant bit rate can be problematic, then I think the article has merit.


Author: prescienta

Prescientas ruler

12 thoughts on “In Defence of Mobotix”

  1. Morten, I too thought it was a good post–in as much as it highlights distinctions between H264 and MJPEG. MJPEG may be with us for a long time for certain uses (durability across chaotic network conditions is a favorite of mine). There’s also the merits of how easy it is it “work with” one vs the other, as you point out, encoding, decoding, transcoding, recording, etc.

    But comparing the quality of MJPEG to the fixed bitrate H264 used in certain low-bandwidth streaming scenarios (such as iTunes!) is a bogus argument. Those are very different contexts than our industry. I’d rather see MJPEG side by side with H264 on comparable hardware and networks at the same bitrate to better judge their respective (quality) merits.

  2. I feel that a lot of people treat H.264 as a panacea, blissfully ignoring the caveats. Yes, if you know the knobs and levers, you can tweak H.264 to your hearts content, but that is often not how it is being sold or presented to the end user.

    MJPEG is easier to understand than H.264 for sure. In H.264 you may look at a relatively static scene and think that you have fantastic HD quality at a very low bandwidth. When you finally have an incident, THEN you realize that the system was fatally misconfigured, and the video is useless.

    What they could have done is to mention that most cameras support VBR, and described how that would impact the video. Instead they bring out MJPEG..

    I just thought John was being a little harsh (but I realize that it is not an entirely uncommon thing πŸ˜‰ )

    1. Thanks,

      And a good question too.

      I think everyone has the right to change their mind (and thankfully, a lot of people do), but I suppose you can get tired of all the hyperbole that sometimes emanate from our companies. Every other company out there is the self proclaimed “leader in IP Video Surveillance”, they all have the most innovative, leading edge, easy-to-use, open platform and so on (we do too, but that’s actually true πŸ˜‰ )

      If I read Johns article again, I suppose he is not really agains MxPEG per se. As Steve Mitchell points out, Mobotix is not entirely honest about H.264; it’s true that broadcasters user fixed bandwidth compression, and they pack “too many” channels into their available bandwidth. This causes noticeable degradation of quality when there’s a lot of motion in the frame. But that’s because BROADCASTERS cheat their clients. It is a feature of H.264 and not a deficiency, and it is certainly not something that MxPEG would solve either.

      My problems with H.264 are entirely different, and I see a variation of MxPEG as a very interesting alternative πŸ™‚

  3. Well you never know, he may have indulged in a change of mind, or then again, he may still stand by his original statement that MxPEG is better! πŸ˜‰

    1. Here is an idea for MxPEG V2.

      When calculating the delta for each frame, always use a keyframe as reference. Do not use the previously reconstructed frame. This allows the app to drop intermediate frames. It also allows the recorder to drop every other frame as the frames get older.

  4. Looks like you have some good ideas, have you thought about passing them by MOBOTIX? (MxInstaller is like what Macworld magazine is to Apple, we write about MOBOTIX products but we don’t influence their product development.)

  5. Honovich is such a hoser.

    Forum quote (cut and pasted) “Honovich had inadvertently backed himself into a corner with his forum post. What had him freaked out as you put it, was that his public endorsement of MxPEG over H.264 would have angered most of IPVM’s paying customer base. Which is why he wanted it to go away. It’s interesting to see that the original ACTi forum post was been removed.”

  6. I think he can change his mind, that is ok for sure. But IPVM prides itself on backing opinions with actual testing. So my point is, where is the IPVM research data to prove that — H.264 provides little practical/technical benefit compared to MxPEG? I think it’s irresponsible for IPVM to make such statements without backing it up with some sort of evidence.

  7. Like a lot of ill informed press, IPVM produces tons of half baked articles and reports threaded with statements that perpetuate the idea that everything has to be h.264. They almost dictate that if you’re not using h.264 you’re out of the game. Which is why, to my mind, IPVM represents the problem within our industry, that “good enough” is the standard.

    Which is WHY (ironically) I do agree with IPVM that “h.264 provides little practical benefit”.

    IMO, security is the market sector that should NOT be looking at h.264 (or HEVC).

    Our business may occasionally settle for h.264 when installing security systems into budget restricted places like small shops or homes. But for commercial use we only use motion JPEG recording, because we want to make sure every image gives us the highest chance of identification. We haven’t seen that that with h.264 – yet. MPEG processes (image quality) vary so much and the implementations are mostly NOT good enough. As a caveat, we do use h.264 for displaying live to the monitor – but never for recording as rule.

    The way I see it, what’s the point of recording in high resolutions if you strip out 80% of the captured data? What is needed is data rich streams.

    The bandwidth and storage advantages are irrelevant for us as storage is so cheap and network pipe is so big. Security systems don’t need 4K compression over 4G. Save it for youtube.

    I just wish the industry would understand the real requirements of surveillance and not automatically adopt a code or standard because “it’s the newest thing” as though being the latest justifies the end, which in just means compromise.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s