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.

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.

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.

Original picture by mamamusings, licensed under the CC-BY-SA.


After color grading (Magic Bullet’s “King of pain” template)

After 3.5 years with the same slow 3 Ghz P4, it was time to upgrade. Funny thing is, I was not going to, but looking at prices at DELL’s site with my husband (who was also looking into getting a new PC for Photoshop to replace his old G4 Mac), I ended up chatting with a DELL representative who gave me $250 off on a QuadCore 2.4 Ghz XPS 630. She added 64bit Vista (will use mostly the 32bit of Vegas Pro though), 6 GB RAM, and a 640 GB drive (all options that were not available on DELL’s XPS site). If she was not doing these changes for me, I wouldn’t have gone ahead (in fact, I wasn’t looking into buying yet as I am waiting for the new crop of AVCHD cameras first). Thing is though, my PC is slow and my XP is slowly degrading (it now takes a full 4-5 minutes before my PC is usable after a clean reboot).

The only thing I was not careful about though was to get the ATi HD3870 GDDR4 instead of the GeForce 9800 GT 512MB. The ATi model has an additional HDMI port and it’s faster in sheer hardware speed (bus/memory throughput) which is what I am mostly interested rather than special drivers/APIs or OpenGL (as Vegas don’t supports those anyway). But on the other hand, Magic Bullet for Editors 2.1 is only accelerated with GeForce cards, so I am kinda stuck here (I still use the older version of Magic Bullet even if I own the brand new version, as the brand new version is too buggy).

Apple rejected a Podcast app from its AppStore for having a “duplicated functionality” with iTunes. The developer explains that the current podcast solution requires iTunes syncing — and therefore a Mac/PC –, while his application can download the podcasts directly from WiFi/3G/EDGE, without the need of syncing. After reading this, I posted on his blog, and emailed him the following:

“Wanna bet that the problem was not the “duplicated functionality” but the amount of data that your app would have to piggyback on AT&T’s EDGE and 3G? I am willing to bet that Apple has a contract with AT&T (so AT&T could allow them to create the AppStore in the first place — as you remember AT&T was not loving the idea) that no app can use over XXX amount of data per usage. And your app uses A LOT of data.

At least this is my personal opinion (I have no [insider] insights or clues, just an opinion based on my experience with this industry that I have reported for years now as a tech journalist). To me, the “duplicated functionality” is just an excuse for the real reason behind all this. Apple can’t tell you the truth because then AT&T will be pissed off, and Apple will look like it’s bending over to AT&T. So they just give you that stupid excuse. Again, just my personal analysis of the situation after reading your blog.”

He replied:

“But why not just ask me to put that limitation in place. I would do it.”

And I replied back:

“Because there was the strong possibility of you not agreeing with it as it
would severely limit your app and therefore your sales, and this would also
expose them as bend-overs to AT&T. Besides, it’s not in Apple’s nature to
sit and negotiate that stuff, they either allow or disallow…”

I have to also point you in an older blog post of mine where I discussed the limitations imposed by the license of the iPhone SDK or Apple’s iron control over it. Among those discussed was the “duplicate functionality” point, and some of my readers didn’t believe me back then that this was even a real point that Apple would exercise control over. Well, guys, when I write something, I know why I am writing it.

I love hens. These are my grandmother’s hens I tried to catch on August in Greece.

“A 22-year-old woman in the United States is publicly auctioning her virginity to pay for her college education, sparking a heated online debate about sex and morality,” says Reuters.

Personally, I support the idea. I am for a world without the need of prostitution of course, but read more carefully the article to see that life is not really Utopian:

– Her mother, a fourth grade teacher, does not agree with her decision.
– The auction will take place at a Nevada brothel where her sister is working to pay off her college debts.

So, what do we have here? A mother, who can’t pay for her kids’ college. A sister, who’s been down that road before and she has to sell herself repeatedly in order to pay the college debts. If anything, “Natalie” does the clever thing by initiating an auction. By doing this one-time thing, she clears herself from future, daily even, prostitution.

But I ask you: why isn’t their family able to pay for their college? Instead of having the mother “disagreeing”, where is her second job to help pay for her kids’ education? Where is the father? In Greece, there is no family that wouldn’t do their best to support financially their kids during university or college. And going further: why do you even have to pay for education? For example, I think Stanford Uni costs about $200,000 a year these days.

This blog post will have to go around the same path as some of my older ones: college education in the US is extremely expensive, in sharp contrast with most European countries where entering a university or college is usually free or low-cost. The fault here is not the morality of “Natalie”, but the system she has to abide to. So she simply plays out according to the rules of the capitalistic system. She has no alternative, because the alternative would be not just a night off, but many years of prostitution — like her sister.

Unless her college offers her a free tuition, even if it would be just for PR reasons, “Natalie” does what she must do to survive and have a future. I rank education as that important. If you have a problem with all that, write to your congressman.

Asking if I would ever do what she does, the answer is “no”. But she’s not me, and I fully understand her reasons for doing so.

If there’s one person in the OSS community that I am allergic head to toes, that’s Steven J. Vaughan-Nichols. The guy is non-objective and his kind of talk reminds me why I didn’t want to do OSNews anymore (I guess I owe him that).

In the latest of his editorials he writes that Linux might equal the graceful Mac OS X: “[…] between the driving pace of open-source development, and Shuttleworth’s millions, I can see it happening. Why not? After all, Mac OS itself is based on FreeBSD.”

Argh. This just shows that this person has no freaking idea what he’s talking about. Like the reason that OSX is graceful is because it’s using some of FreeBSD’s kernel code. How is that guy still on the internet?

Mac OS X is graceful because it has a team of good engineers and designers working on it under strict guidelines and targets, and under the single authority of Steve Jobs who has a clear idea in his head as to what he wants from his product. Mark Shuttleworth isn’t Steve Jobs. And worse, even if Mark was as good as Jobs, no one gives a shit. 95% of the OSS developers will give him the finger on his requests to fix this or that, and the rest 5% will try to eat out his millions. And in the meantime, that 5% of developers will be so far away physically from each other that would make it impossible to create a truly coherent OS. So in my opinion, Mark is wasting his money on a dream. [Update: Do NOT underestimate the importance of engineers being physically together. Read my reply in the comments here explaining it.]

If he really wants something done right, he should start a new Google project and use the company as his vehicle by hiring all major project OSS maintainers (including Linus) and a new crop of engineers. All at Google’s campus. No tele-commuting. Mark, either take control of GNU/Linux in some way, or retire. Buy an island instead. OSS in its current form hasn’t worked for 20 years in terms of desktop experience, there is no reason why it would start working now with a few extra millions poured into the sauce. If mediocrity and being No3 is your goal, you have already succeeded. If changing the world is your goal, then you should first change how GNU/Linux gets maintained and developed.

And while you are at it, never give SJVN an interview. Tell him you’ll call back.