sampa : colin’s blog

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)

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?

I’ve used update sites for various Eclipse plugins over the years, but for the most part have manually downloaded and linked to WTP. Now that Callisto is ready, I decided to go the update manager route. After installing a bare Eclipse SDK, I selected the Callisto site, picked the WTP components, BIRT, and all their dependencies, and let it go ahead and download.

After 10 minutes, I found the update manager stuck with a message that it was unpacking a certain .gz file that is part of the download. The dialog was still quite live, so after seeing that nothing was changing (71% completion percentage) I hit cancel. Now the cancel button is greyed out, but nothing else has changed. It looks like I’m going toi have to simply kill the Eclipse process.

Not a great start for Callisto on my system…

Update 2006-7-4: On a 2nd attempt, same story, different archive. org.apache.cactus_1.7.2.v200606181221.jar.pack.gz is stuck. The status bar says 69% forever.