Oh, don’t we all enjoy labeling things? There’s reassuring to be found in the idea that A is better than B. No disclaimers, no gray areas. Just pure and simple… “Better”.
One of the best things about the good old JPEG is that it is fairly simple to fit the video to the recipient device in real time. Imagine that we have a few 5 MP H.264 cameras in our system. 99% of the time, the video is placed on disk, never to be looked at. So 99% of the time, JPEG is worse than H.264 (apples to apples, H.264 is better but sometimes you crave oranges). If the client always connects via a fast connection, and always has good resolution on his device, then fine; stay with H.264, but what if sometimes you connect via a low-res device (phone), or have low bandwidth (phone and ADSL)?
Mindlessly streaming H.264 over a low bandwidth connection will be a horrific experience. You can’t use YouTube as a reference, because YouTube is playing back recorded video and thus the latency can be extremely high. The problem with H.264 is that you need ALL the bits and pieces, otherwise the quality will degrade and you will experience “ghosting”, so if the server has a 10 MB GOP, containing 2 seconds of video, then you need to wait until you get the whole thing, which could take a while. Then you need to decode the first frame of the GOP, which gives you a 1920×1080 frame. This frame is then brutally scaled down to 640×480. Assume that it takes 10 seconds to process the entire 2 second GOP (sending, decoding and scaling), now you are already 8 seconds behind real time, so we need to skip ahead 4 GOPs to avoid the latency building up, making the video look very, very strange.
To resolve this, the NVR must support multiple streaming profiles, which means that the camera must support them too, or alternatively, the NVR must be able to transcode the video on the fly, while not jeopardizing the recording. And – by the way – all of this tweaking and turning knobs is to be done by someone who is already struggling with a fairly complex piece of kit.
Transcoding H.264 to H.264 is an expensive proposition (the encoding bit). It can be done, for sure, but it will come at the cost of other features in the app as development resources are directed towards solving this particular problem. Transcoding H.264 to MJPEG is much more flexible, and since MJPEG is supported on a wide range of browsers making it fairly simple to create a mobile app.
Sure, with infinite development resources, we could do everything, but lets stay within the realms of reality.
As a little commercial plug, here’s a small test i did with some video hooks in Heimdall.