Dirty Little Lie? Is Digicam h.264 / AVC Video Really Motion JPEG in Disguise?

Starting a few years back, a lot of digital cameras, even pocket models, started supporting video capture as well as the taking of traditional still (in JPEG and sometimes RAW format) pictures. Invariably, the supported video format was Motion JPEG, with pretty large file sizes. Then in the last year, cameras supporting h.264 / AVC (a real and very modern video codec), with the promise of smaller file sizes, have appeared. But all is not what it appears to be…

The reason digicams initially used Motion JPEG as their video capture format is pretty simple: in a Motion JPEG video, each frame is essentially a separate still JPEG image, with no real relationship to the frame before or after it. This makes Motion JPEG very simple and non-CPU intensive to record, since the digicam just has to be able to produce still JPEGs at the proper rate (e.g. 30fps). And digicams already know how to create JPEGs, so it’s mostly a matter of making sure the CCDs that do the video capture are fast enough and the JPEG production is fast enough, basically an incremental upgrade to existing camera circuitry. But Motion JPEG has a huge (literally) disadvantage compared to a real, modern video codec like the h.264 / AVC from MPEG-4 (what Blue-Ray uses), or compared to the somewhat less sophisticated (original) DivX, and even compared to the older h.262 found in MPEG-2 (what DVDs use). Because a Motion JPEG frame can not use any data from a previous frame, or have any of it’s data used for subsequent frames, it’s very inneficient, and resultant file sizes are quite large.

I was pretty excited to see some digicams appearing with h.264 / AVC support in the last year, and around the end of 2008 I bought a Canon SD880 IS, which (via its “Digic 4″ processor) is able to product h.264 video. In general, it’s actually proven to be a really nice little camera, also having a wide angle lens, and supporting optical image stabilization.

I was however surprised by the size of the videos it takes. They really seemed very large compared to what I thought they should be, based on the size I’ve seen for movies in DivX or h.264 format. So I’ve done a little controlled test, not necessarily the most scientific, but pretty revealing, by shooting a 1 minute h.264 video panning back and forth (in a hockey rink) with the Canon, and also shooting a similar video in Motion JPEG format with my brother’s Panasonic DMC-TZ5.

1 minute 640×480 h.264 video from Canon SD880 IS: 75.6 MB

1 minute 640×480 Motion JPEG video from Panasonic DMC-TZ5: 74.3 MB

I then used Handbrake to reprocess the Canon video with h.264 as both the input and output format, using the high quality “film” setting and got a much smaller size.

1 minute 640×480 h.264 video from Canon reprocessed with Handbrake:  13.6 MB

What’s going on?

Pretty simple. I don’t think h.264 video from the Canon, and probably most digicams out there, is “real” h.264 / AVC video. h.264 video encoding is actually pretty CPU intensive. Even decoding (for playback) is pretty CPU intensive, as seen in all the Atom based Netbooks out there which can’t properly play back HD video. I think what Canon (and probably others) have done is shove completely separate frames in that video stream, essentially Motion JPEG in a h.264 envelope. This would require a lot less processing. Given fact I was able to reprocess the h.264 video from the Canon and get a 5.5x reduction in size with no visible quality loss, there is a pretty good case to support this. Basically, the reprocessed video does reuse info from frame to frame.

So be aware, your nice new digicam putting out nice h.264 videos is not really doing a great job for you, in terms of file size at least. Does this matter? Quality-wise, not really. Quality might even be better than if it tried to do a real h.264 encoding (reuse data from frame to frame) but didn’t have the processing power to do a proper job. And it doesn’t matter when you upload the video (aside from upload time) to the likes of Youtube, since Youtube will reprocess it to its own format anyway. But if you intend to keep these videos around on your hard drive, or burn them to some other storage, or put them up on your web site, it’s well worth spending a few minutes to reprocess them with Handbrake (or something similar).

My guess is that as digicams continue to evolve and be enhanced over the years, their processing power will actually be good enough to do proper h.264 / AVC encoding right in the camera.

For interest’s sake, I have uploaded the 3 videos to Youtube. The Youtube upload doesn’t mean much, since Youtube will reprocess them to its own internal format, but if you look at them (in High Definition mode) you can see that they all have about essentially the same quality. Note as an aside that the Panasonic does have a pretty much nicer (bigger) lens than the Canon. Note also that Youtube seems to have had some issue in converting the beginning few seconds of the reprocessed h.264 video. I have not bothered to investigate this since it does playback fine in original form before uploading.
Original Canon h.264 video (high-quality mode)

Panasonic Motion JPEG video (high-quality mode)
Reprocessed h.264 video (high-quality mode)

Latest comments across all posts

Recent Posts

Does this RAD make my ass look fat?

I recently needed to download and install IBM RAD (Rational Application Developer) to do a demo of a Spring project in that environment. It’s been a while since I’ve hard to touch RAD, so time had done it’s magic and put it’s rosy-tinted hue around that last experience, or at least dulled the memory a bit… It’s hard to imagine that something could make Eclipse look svelte and speedy, but I guess if anybody is up to this task it would be IBM. The download was 3GB compressed (!), and in the one archive, includes code for all platforms. What kind of insane product management logic would decide to turn what would probably be something like an already bloated 2GB platform specific download into an even more bloated 3GB multi-platform download?


Only your vote stands in the way of another 4 years of nucular and eye-raq

I think I’m just about ready to heave , only 50 minutes into the vice-presidential debate, and Palin has already already pronounced nuclear as “nucular”, and iraq as “eye-raq”, easily a half dozen times each.

Blargh!


“The Mac lets you code anywhere, anytime.”: Ahh, the irony

I just got an email from Appie with the following text

ANY PLATFORM, ANY LANGUAGE, ANYWHERE

Why are the hottest new applications being developed on the Mac? Because the Intel-based Mac lets you easily develop for virtually any platform, language, and programming environment. And now, you can test and run applications on UNIX, Linux, and even Windows, using just your Mac*. Plus, with powerful Intel processors, MacBook and MacBook Pro let you code anywhere, anytime. Learn why developers choose the Mac to create cutting-edge applications.

Sure, if you don’t need to use Jave 6 / JDK 1.6, released almost 6 months ago now, with Apple support nowhere in sight. It looked like it would be out with Leopard, but now that Leopard has been delayed to October, who knows?

Spring 2.1 now needs JDK 1.6 to _build_ (it runs very well in JDK 1.4+), so trying to build Spring CVS HEAD for those of us using Macs is now a major pain. Fellow Spring Framework developer Thomas Risberg has figured out a sort of workaround, basically taking the JDK 1.6 Mac preview from last Sept. and patching some problem classes with equivalents from the final JDK 1.6 for Linux/Windows, but this is painful and a stopgap solution at best.

So I guess the message from Apple really is, “ANY PLATFORM, ANY LANGUAGE, ANYWHERE, once we ship the iPhone and can get back to business on other stuff…”


10 Months From Maven 2.0.4 to 2.0.5. What’s Wrong With That Picture?

Maven 2.0.4: released April 11, 2006
Maven 2.0.5: released February 14, 2007.

I’m really glad Maven 2.0.5 is out, it fixes quite a number of important issues (along with some more more minor stuff and enhancements). But for a tool which should be one of the key enablers of an agile and frequent release process, something seems broken somewhere if it takes 10 months to put out a point release when there are enough issues of this magnitude.

Of course, Maven is mostly built by volunteers, with limited resources. Should it be held to a different (less than ideal) standard because of this? I don’t think so. There first of all seems to be a decent amount of developer activity, but even in the face of more work than time/people to do it, I would argue the project (like any software development activity) when working on bugs and requirements needs to triage the list of things that are worked on, and focus on a regular and more frequent release process. Anything else is ultimately damaging to people’s confidence in using Maven… It’s interesting that on the dev list, as far back as Nov. 2006 there was a thread asking for the release of 2.0.5, with mention of user frustration after no release in more than 5 months, with many serious issues fixed. Bad enough; how did that become 10 months?


Best Halloween quote ever

So last night I went out trick or treating with my kids and my brother and his son. At one house, the kids collected their goodies and started walking back to the street, and with the door open and the homeowner still standing there, my 5 year old nephew took a look at the Coffee Crisp bar he had received, and yelled out, “Daddy, can you throw this away? It’s hydrogenated!”.

Looks like my brother has been putting the fear of trans-fats into his son…

Older Posts

First attempt to use Eclipse Callisto update site not very inspiring

The Rewards of Being an Open-Source Developer

Google Calendar is Nice, But Lacks Some Key Group Functionality

Spring Framework at EclipseCon 2006: Stop by and Say Hello!

JTA Does Not Equal Automatic Support of Two-Phase Commit!

BEA to open-source JPA (EJB3) persistence library based on Kodo

Spring is Most Certainly Designed for Scalability

Groovy Then and Now, It’s Like Night and Day

Spring Experience 2005 Kicks Off

NYJavaSIG talk on Spring, Tomorrow Night (Nov. 16th)

Spring Framework 1.2.6 Released, Full Steam Ahead to 1.3

Survey of AJAX/JavaScript Libraries

Spring Web Flow Allows Seamless Integration with Multiple Web Frameworks

Spring at BEAWorld 2005