Archive for September 15th, 2008

The Fall

If you are a cinematography enthusiast, then you should definitely buy the Blu-Ray disc of “The Fall“. It’s shot with a Velvia-like film, and it looks fantastic. The director of photography did an amazing job, and if that’s not all, the movie and story-telling itself is something.

ProRes for Windows

Apple released last month a Windows decoder for their ProRes intermediate, visually lossless, codec. Quicktime 7.5.5 also includes the decoder, although there is no encoder for Windows.

This release is actually godsend, as it can help with the interoperability of various platforms. Here’s a scenario for video editor workers need to collaborate with Linux, Windows and Macs, but they don’t want to use uncompressed footage.

Mac: Final Cut Studio, Avid Codecs LE freeware, and the freeware Perian codecs installed.
Windows: Huffyuv, Avid Codecs LE freeware, Lagarith, and Quicktime 7.5.5 installed.
Linux: FFmpeg or Mencoder encoder installed.

Exporting from Mac to Windows: Use ProRes or Avid DNxHD.
Exporting from Windows to Mac: Use Huffyuv in YUY2 mode or Avid DNxHD.
Exporting from Linux to Windows: Use Huffyuv in YUY2 mode.
Exporting from Windows to Linux: Use Huffyuv in YUY2 mode.
Exporting from Linux to Mac: Use Huffyuv in YUY2 mode.
Mac to Mac: ProRes, Avid DNxHD, or the less good AIC.
Windows to Windows: Huffyuv in YUY2 mode, Avid DNxHD or Lagarith RGB/YUY2.
Linux to Linux: Huffyuv in YUY2 mode.

Exporting from Mac to Linux: You will have to either use uncompressed, or export with the Mac version of Lagarith (in RGB mode), load it on a Windows PC (which should also have Lagarith installed), and then use either a Windows video editor or mencoder that can read “Video for Windows” AVI files (so it can read your Lagarith Mac file), and export in Huffyuv in YUY2 mode. Then this Huffyuv file would be readable by Linux. Expect color shifts in all those re-encodings, although no major quality degradation.

Diet Recipe: Eggplant and Peppers Pasta

This nice vegetarian dish, which a variant I had today for lunch, only has 200 calories.

Ingredients (for 1)
* 45 gr of Ronzoni Healthy Harvest penne rigate (140 cals)
* 1 small onion or shallot, chopped (4 cals)
* 1 clove of garlic, minced (2 cals)
* 10 thin slices of zucchini, cut into halves (5 cals)
* 50 gr of red, yellow and green bell peppers, coarsely chopped (16 cals)
* 1/2 cup of fat-free vegetable (or chicken) broth (8 cals)
* A half of a big tomato (15 cals)
* 40 gr of eggplant (10 cals)
* Black pepper to taste
* 0 calorie non-stick spray

Execution
1. Cook pasta as per instructions, drain, set aside.
2. In a cooking pan, spray with the non-stick spray. Add the onion, zucchini & peppers and stir fry until the vegetables become softer and brown-ish.
3. Grate the tomato and eggplant using a cheese grater. Add both into the cooking pan.
4. Add the minced garlic, black pepper and vegetable broth. Cover, and simmer for a few minutes until there is almost no liquid left in the pan.
5. Toss the pasta in, mix well, serve, and enjoy.

Eggplant and Peppers Pasta

Intermediate Codecs: the face-off

One question that I am asked regularly by new videographers is about what codec they should use for archival and collaboration, in other words, for “intermediate” usage rather than user playback usage. So I spent all afternoon today making tests with some of the most popular and modern intermediate codecs for PCs: Avid DNxHD & Meridien, Lagarith, Cineform, Matrox i-Frame HD, Huffyuv, FFdshow TryOut’s FFV1 & MJPEG, and finally, HDV MPEG-2 by MainConcept.

Setup

I used Vegas Pro 8.0c as my vehicle for these experiments. The PC used is DELL Dimension 8400 with a Pentium4 at 3.06 Ghz with Hyperthreading, 3 GB of RAM, two SATA drives one of which holds the temp files and the other one the source HDV file (and rendering back to the first one), and a 256 MB GeForce 86000GTS, under Windows XP Pro 32bit. The source file is a typical 15″.00 sec HDV .m2t file: 25mbps, 1440×1080/60i (interlaced). The 1080/60i template was used on Vegas’ Project Properties dialog, but with “best” quality and the “interpolate” algorithm selected (everything else was left in their defaults).

For the playback speed benchmarks the preview windows used the Vegas default “preview (full)” and “preview (auto)” qualities. The “preview(auto)” was exactly set to 1/4th HD window, meaning, a playback area of 640×360. The “preview (full)” was displaying on my second full-HD PC monitor, meaning that the video was displaying exactly in 1:1 1920×1080 size (no resizing). I benchmarked the playback speed on both windowed 1/4th HD and full 1:1 sizes because in full size the graphics card is taxed much more because of the bandwidth involved, and so it’s usually slower. Normal users would usually use it in 1/4 HD preview windows on their home PCs, but professionals are more likely to use full HD preview second-monitors, so I thought it would be good to test both.

Notes on some of the codecs

Cineform NeoHD v3.8.0 used in three different qualities: Medium standard, High upconverted to 4:4:4 and Higher upconverted to 4:4:4. For some weird reason that probably has to do with their “clean artifacts” algorithm, as you can see in the “quality difference” chart the quality seems to be better in High mode rather than in Higher.

For Avid DNxHD, I used its 10bit, 220mbps and 8bit, 145mbps modes, both exported at its highest 1080/60i preset. However, as you can see below, there is a UI bug on their codec preferences dialog, which didn’t let me choose anything for the “alpha” option. I wonder how can Avid release such a buggy interface. I should also mention that Avid installed its codecs to work under the Quicktime .MOV container rather than the AVI or MXF containers, which has a speed impact under the PC (just because Quicktime under Windows sucks goats).

The Matrox Mpeg2 i-Frame HD was used at 100 mbps, just so it emulates the product that it tried to replace: DVCPro HD. I should note two things with this codec: first, it won’t let me export above 1440×1080 (although I used a 2006 version, I don’t have a newer one as Matrox doesn’t give these for free), and it won’t playback in the 1/4th-HD preview window under Vegas because it refuses to resize itself (I get a black screen). It requires either a 1:1 playback size, or to be viewed in “good (auto)” preview quality mode rather than “preview (auto)” that’s Vegas’ default. UPDATE: Version 1.0 of the codec fixes the problems! Not tested here though!

For the MJPEG codec, I used July’s FFDshow tryout’s preference panels, selected 95% quality, and I specifically told it to optimize “for quality”.

For the FFV1 codec, again FFDshow tryout’s pref panels were used, using the default 422p quality and everything else was left as is.

For Lagarith, I told it that my CPU is multithreaded, and I tried it in three different modes. I tried Huffyuv in YUY2 mode only, as its other modes create too huge files.

From all these codecs, Cineform NeoHD and Matrox’s i-FrameHD codecs are available only via purchase (in Matrox’s case you must buy their hardware to get access to these codecs, they don’t distribute them otherwise, even if they do work without the said hardware). All the other codecs are either freeware, open standards, or open source.

Test 1: Encoding times

MJPEG, Cineform and Huffyuv are the fastest contenders in this first competing category. The MSU codec should just suicide. The rest are just “ok”.

Please note that on Vegas Pro 8+ and Vegas Platinum 9+, HDV source footage doesn’t need to be re-compressed again in HDV if you didn’t modify that footage in any way in the timeline other than split/cut (e.g. adding plugins, pan, crop, transitions will force Vegas to re-encode). I disabled the “no-recompression” trick and force Vegas to re-encode in order to measure its encoding speed for this test.

Test 2: Filesizes created

This test is not exactly comparable as some bitrates were decided by the user (e.g. I specifically told Matrox to use 100mbps instead of its default 50mbps) or by the format (HDV is always 25mbps), but for some codecs it’s the codec itself that decides how much bitrate will use. So at least for these codecs, this test is still relevant.

HDV here creates the smallest file size, being a format that’s in between of being a delivery-grade format and an intermediate-format (it kinda feels like it has an identity crisis). MJPEG also created a small file, but the best file size — in conjunction to the quality it also delivered in the test below — was Matrox’s. Cineform is a very good choice too here.

As for Lagarith’s RGB (and Huffyuv RGB which was not tested specifically, but it’s similar to Lagarith’s RGB), yes, it’s a big file, but as you will see below, it had zero quality degradation. The only one that was truly lossless.

Test 3: 640×360 preview playback

Please note that the speed of playback can be different from application to application. I use Vegas here as my vehicle because, well, that’s what I use daily. Vegas is popular lately with the “geek” side of the new wave of amateur artistic videographers too, so it’s relevant to the kind of readers I have on this blog.

So, as you can see, HDV and Cineform Medium and High quality, and to a lesser extend its Higher quality, are speedy. They playback on a Vegas 1/4th HD preview window under “preview (auto)” mode (which is what most people would use it as), on full speed at 29.97fps. The rest, are one, big, fat, disaster. Admittedly, Avid’s DNxHD might have fared better if it was under the AVI container that Vegas prefers.

Please note that Matrox’s codec failed to work in this test, as explained above. [Note: I used “0” frames for Matrox to create this chart, but we used “9 fps” in order to create the last chart at the very end of the article (same value as in its full HD preview playback), because without it, the chart’s formula was dividing by zero and was going berserk.]

Test 4: 1920×1080 preview playback

HDV is maintaining its full speed on this test, but every other codec comes to its knees, including Cineform. The playback difference for Cineform is staggering in 1:1 size compared to the 640×360 playback window. However, I have found that Cineform is pretty usable at that speed anyway, and that it also uses a notorious caching system that when playing back the clips in the timeline a lot of times, it gets faster and faster each time.

As for FFV1 and MSU, they should just die together. I have no mercy for poor engineering.

Test 5: Quality degradation after 1 re-encoding

I used the “perceptual image diff” utility to conduct this test (thanks goes to my husband JBQ, for the tip). Because all these codecs are either true lossless or visually lossless or barely-lossy, I needed to quantify their quality loss rather than let my eyes fool me (or Cineform’s David Newman would eat me alive). I selected the same frame each time I was testing a codec, de-interlaced it, export it as PNG, and compared it with the same (de-interlaced) frame of the original HDV source footage.

What you see here is that FFV1 has a serious bug in 422p that made 1.4+ million pixels look different over the original 2+ million pixels that exist on a 1920×1080 playback area. It is visibly different, and I can only hope that this is a bug and not how it would really perform. We also see that MJPEG sucks as an intermediate format (and I am writing this because many users under Linux use that same MJPEG codec for intermediate needs). HDV is only “ok” and Cineform is looking good to the eyes, but not as good when you look at the numbers (curious, huh?). Instead, Avid’s new DVxHD codec does an amazing job.

The biggest surprise is from Matrox’s i-Frame HD codec though, that it manages to have a minimal degradation even if it only used 100 mbps for its encoding compared to most other codecs in this test. If only Matrox had some clue to make this an open codec or even sell it.

Lagarith RGB here had 0 pixels of difference (meaning, 0 degradation of quality), it was the only codec that did a real lossless job. But of course, as you see above, its file size was big. Huffyuv in YUY2 mode seems to be a good choice overall too.

UPDATE: Cineform’s David Newman was kind enough to provide me with a copy of the Cineform Neo4k variant, which allows for 4:4:4 encoding and decoding. When using this feature to encode/decode a progressive source (rather than an interlaced one), the pixel differentiation is around 20,000 pixels, which places that aspect of comparison around the same (or better) level than the DNxHD codec. However, Neo4k costs $1000.

Test 6: Quality degradation after 5 re-encodings

The true value of an intermediate format is to sustain quality after many generations of re-encodings — something that’s normal to happen in a broadcast environment where different editor workers are sharing footage and each one modify it before it goes on air.

I only used four codecs in this test because it was getting late and I had to manually go around the fact that Vegas would not re-encode footage that didn’t change and used AVI or HDV as its container: I created TIFF uncompressed files from the same frame used earlier for the perceptual diff utility, and was re-encoding that in progressive mode, taking another grab as TIFF from that and re-encoding, etc etc, 5 times over. I hope it makes some sense.

For Avid DNxHD the TIFF workaround for Vegas’s no-re-encoding ability was not necessary, as Vegas doesn’t support the no-re-encoding trick for MOV containers. One thing to note here is that MOV is slower on PCs, so while in the first export from the source HDV it only took DNxHD 1′.53″ to encode the 15 second file, when going from MOV to MOV it took nine minutes! Avid, please give us some AVI love too.

Anways, this test not only show us how terribly sucky HDV is when it’s re-encoded over and over, but it also shows us that the perceptual diff utility is not always tell us the whole truth as you would think it would. Numbers can lie, in a way. You see, the Avid DNxHD codec was having a weird bug. It was screwing up the interlacing as you can see in the picture below. After 5 re-encodings, wherever there is some motion in the frame, it now looks like crap! The only reason why the DNxHD scores so well in the chart below, it’s because only a small part of the frame was in motion. If this was a high-motion frame, the DNxHD would have been in huge, huge trouble.

The Matrox’s 100mbps i-Frame HD codec had the smallest degradation percentage compared to its first generation version according to the numbers. However, looking at the picture, there are some visible artifacts.

Now, because I am difficult to convince that Matrox’s codec is that good, I did one additional test for the Matrox i-Frame HD. You see, I am using HDV MPEG-2 as my source footage, and the i-Frame is also MPEG-2. It is very possible that the codec might “recognize” the kinds of artifacts HDV creates, and “play ball” with them as its own artifacts would be similar in a way. So what I did was to use an AVCHD h.264 1440×1080/60i .mts file instead of HDV, export using the i-Frame HD 100mbps codec, and then compare with the perceptual diff utility their first frames for any changes. For this AVCHD frame compared, the i-Frame HD yielded 105,737 pixels of difference over the original 2 million pixels, which is again, a good performance. And given that this AVCHD frame I used had really high-motion in it, it does make it clear that the i-Frame is a good codec when it comes to its filesize/quality ratio.

However, Cineform is a weird contender here. If you see their 5th generation picture, there are no artifacts. And yet, the perceptual diff says that there is quite some difference over the original HDV. It gets weirder: Cineform visibly has in fact fewer artifacts over the original. Obviously, a “cleaning sweep” algorithm is at work here. It analyzes the image and removes everything that looks like an artifact. This way, it’s able to keep a good overall quality after many re-encodings, by cleaning up after itself. While the numbers in the chart say otherwise (show some degradation), to the eyes, the Cineform codec is the most pleasing.

Conclusion

So, what’s the best codec? Well, it depends. If everything was black and white we would already be having a monopoly, now wouldn’t we?

If your source footage is HDV (and nothing else), and you don’t use any plugins/transitions/pan/crop, Vegas’ no-re-encoding ability will help you in that regard. HDV scores high in the overall performance/quality chart below (performance is an average of the first four tests and quality is the percentage of the fifth one), but it really is useful for Vegas HDV users only and if re-encodings are needed, it loses quality way too much.

If you have the money, go for Cineform. It’s overall very good, and fast to playback during editing. It has a good average performance/quality ratio. Personally, this is what I will be using (the NeoHD variant).

Avid’s DNxHD is one codec that could take over the world if Avid was more careful of its implementation: fix the stupid interface bug, support 4k resolutions, optimize playback speed, give the user the choice of also installing the codecs under the AVI or MXF containers, and of course, fix the terrible interlacing bug that is very visible after a few generations of re-encodings. I just have the feeling that this is one great codec going bad during implementation.

Matrox’s i-Frame HD is also another favorite, but I can’t suggest it because it requires you buy hardware from them before you can get your hands on it. It could do with some playback speed, and fixing of the Vegas bug where it won’t work under the “preview (auto)” mode, but other than that, this is one great codec because of its filesize/quality and low-degradation ratio.

If you really don’t have the money for Cineform, or you can’t stand Avid’s bugs, and you need a visually lossless codec right now, Huffyuv in YUY2 mode is your best choice. I was originally pushing Lagarith to my readers, but overall, Huffyuv proves to be a better rounded codec (and it works also on Linux, Mac and in freeware utilities like the popular “SUPER”).

Overall, stay away from FFV1, MSU and MJPEG (at least of the version of MJPEG FFDshow uses, which I believe is the same as used by Linux users).

View the spreadsheet that includes all the results and the charts, here.

Special thanks to my JBQ for all his help, especially with the spreadsheet formulas that go beyond my abilities.