H.264 Camera and iPhone
  • I recently purchased my first 3MP IP camera and I'm nothing but thrilled about it. It was a huge upgrade from the 640x480 camera it replaced. Since this high res camera relies on h.264 encoding, I've come across a new roadblock and I'm not sure what to do about it. The camera plays very nice with SecuritySpy and the recordings look amazing. Here's the problem though: I can view the stream on my iPhone through the web interface just fine but I cannot view any of the saved files. They're saving as .mov with the camera's h.264 encoding and it's showing as an I ncompatible file type on iOS. I'm confused as to why I can view the stream but not the saved files. Any tips or workarounds? Can I make SS save the captured files in a compatible format? Will that require transcoding and heavy CPU load?
  • I suspect that the resolution is beyond the maximum imposed by iOS. One workaround would be to use the the "Quick" download links provided by SecuritySpy - these are transcoded on the fly to a lower resolution and frame rate, and are designed to be quick to load on slower connections.

    If you set SecuritySpy to encode the video, rather than the camera, this will indeed result in heavy CPU usage (the higher the resolution of the camera the more CPU is required to process those incoming pixels). I doubt whether this would resolve the problem, though this may be worth testing if you are interested in investigating this further.
  • Interesting! Maybe the next iPhone will have support for bigger, badder h.264 decoding. I've been using the quick download links and they've been doing the trick for me. I suppose I've just been spoiled by higher frame rate viewing with the older cameras.

    As far as viewing the stream vs the saved file goes, does SecuritySpy do something to the stream to allow it to be viewed? I can view the full 3MP stream through the web interface and there is no lag. In fact, the stream is excellent quality. Please forgive my lack of understanding, but I'm not seeing the missing piece as to why the stream works but the saved file doesn't.

    Thank you!
  • The downloaded files are QuickTime movies in H.264 format, whereas the live video essentially consists of JPEG images in an HTML page. These two things are handled by the iPhone differently. Rendering large images uses a lot of memory, which is a precious commodity on such a device. I suppose that for web pages - where high-resolution images are quite common - Apple decided to implement this, whereas for decoding H.264 video - where such high resolutions are definitely not common - they decided not to. Rendering high-res JPEG images is less taxing on the iPhone's CPU and memory than rendering equally high-res H.264 video.

    I'm sure a future iPhone will support higher video resolutions but for now I can't think of a solution that's better than using SecuritySpy's quick download links, so I hope these are good enough for your purposes!
  • Ok, I think I'm starting to get a handle on this. Please tell me if I'm on the right track. The 3MP camera I have is set for a single stream at 3MP and H.264 encoding. Rod had mentioned that there are two different stream processes that SecuritySpy uses. One for live view (All Cameras, Main Video Window) and one for the actual recording direct from the camera. (We've been e-mailing back and forth because I can't figure out why the live view jitters but the recordings are perfectly smooth. That's off topic for this post though.)

    So, the H.264 stream is feeding directly into SecuritySpy from the camera and is being displayed in the live view. I assume it is displaying a direct feed from the H.264 stream, but my conversation with Rod is making me second-guess that. This H.264 stream is then transcoded on-the-fly to "server-push JPEG" (same as MJPEG?) when viewing remotely via the web interface. The reason that the stream is viewable on my iPhone is because of this on-the-fly transcoding.

    How'd I do? Thanks again, Ben. I appreciate your help in explaining this process.
  • Yes, pretty much correct :) Here is basically what is going on:

    When the H.264 video comes into SecuritySpy, it has to be decompressed (decoded) in order to display in the live video windows in the app, perform motion detection, generate JPEGs for the web interface etc.

    Ideally though, you want SecuritySpy to capture this incoming H.264 video stream directly to the captured movie files (rather than taking this now-decompressed video and compressing it again) as this gives the best quality and performance. You enable this using the "No recompression of video data" checkbox in the Video Device Settings window, which is on by default.

    For various technical reasons, it is not possible to provide this H.264 stream directly to web server viewers, so SecuritySpy takes the already-decompressed video and compresses (encodes) in into JPEG format for display via the web server. It's not possible to directly transcode H.264 to JPEG; you have to first decompress it and then compress it again. Fortunately, decompressing H.264 video and compressing JPEG video are both quite fast operations (as opposed to compressing H.264 video, which is a slow operation when performed by the computer's CPU rather than by dedicated hardware).
  • That clears it up! Excellent. With this better understanding of how this is all being handled it will help me get on the same page as Rod. Now, I've got an e-mail reply to write about that jitter in the main video window. Thanks so much!

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!