ExtremeTech "Video Codec Shootout"

[Angelus]

Just thought I would post a link to this article. I think they did the test's on a 1-pass basis but I guess it's worth a read anyways.

http://www.extremetech.com/article2/0,1558,1544886,00.asp

[Wilbert]

I think it is a bad comparison:

1) They didn't state their encoding settings.

2) They didn't state the playback settingsw, use of pre/post processing.

3) They didn't state their resize settings (only the final resolution).

4) Sources and Methodology

"For our source material, we turned to DVD movies. Simply put, the production quality of a modern Hollywood movie is far superior to any home movie we could have produced as a test case, so it makes it far easier to pick out differences in fine details. The four clips we chose to encode are as follows:"

This seems to imply that the results also hold for "bad" sources (like tv-caps), which is false.

5) I though I read somewhere that they used 1 pass (CBR or VBR), but I can't find that anymore?

6) I'm confused about this:
"To create our clips, we first dumped the scenes to hard disk as a video using no compression at all. These huge "uncompressed frames" videos were easily several gigabytes each, quite a lot for clips only a few minutes long. Encoding directly from these uncompressed video clips wouldn't really tell use what we want to know about codec performance, as encoding speed would be limited as much by hard drive access as by the codec's efficiency. It's also a bit impractical, as almost all video is captured and edited in a high-bitrate compressed form."

Why didn't they rip the appropriate vob-cells, instead of dumping some decompressed scenes to the hd?

7) From their conclusions:
"When it comes to speed, both of the QuickTime 6.5 codecs performed great, although we wouldn't recommend either of them due to their less-than-ideal quality and lack of adoption in consumer electronics devices."

So, why did they bother to test TWO QuickTime encoders?

"If you're looking to make video that will play on future DVD players, portable video players, and home media gateways, WMV9 is probably your best bet. A great many CE products shipping this year and next will support it. DivX has a reasonable amount of CE adoption as well, and may be the better choice for playback on a PC, as encoding times are much shorter and the quality is comparable."

This is a very strange conclusion. I mean, you don't need to make this comparison in other to conclude that: "If you're looking to make video that will play on future DVD players, portable video players, and home media gateways, WMV9 is probably your best bet."

That could be a reason to add WMV9 to the test codecs, but it shouldn't be a part of the conclusions (in the sense that one codec is preferable above an othe codec for whatever reason).

[Sirber]

No RealVideo? What a shame...

Also, the idea of crop&resize never crossed their mind?

[SeeMoreDigital]

A 1pass CBR or VBR codec shoot might prove interesting, as long as some parameters can be established.

Personally I would love to see a codec that while generating a 1pass capture could also generate a suitable log/pass file.

So if you wanted, you could generate a lower bitrate 2pass VBR encode afterwards!

Cheers

[Animaniac]

Originally posted by Wilbert

So, why did they bother to test TWO QuickTime encoders?


I believe one was QT Sorenson and the other QT MPEG-4.

Originally posted by Wilbert

"If you're looking to make video that will play on future DVD players, portable video players, and home media gateways, WMV9 is probably your best bet. A great many CE products shipping this year and next will support it. DivX has a reasonable amount of CE adoption as well, and may be the better choice for playback on a PC, as encoding times are much shorter and the quality is comparable."

This is a very strange conclusion. I mean, you don't need to make this comparison in other to conclude that: "If you're looking to make video that will play on future DVD players, portable video players, and home media gateways, WMV9 is probably your best bet."

That could be a reason to add WMV9 to the test codecs, but it shouldn't be a part of the conclusions (in the sense that one codec is preferable above an othe codec for whatever reason).

I don't know how they can even say that when all but one of the other codecs are MPEG-4 implementations (and WMV9 and MPEG-4 variant)...

Not to mention that XviD and RV10 wasn't even tested. :rolleyes:

[nFury8]

Notwithstanding the effort that went into putting up such reviews, I guess this only shows that there is really only one place to turn to for thorough and extensive codec comparo. Can you tell me which one it is, children? :D

[bond]

the only usefull thing in this test is this sentence:
It's safe to make the generalization that the DivX encoded clips tended to have a touch more detaili wonder why they didnt test xvid? fear? ignorance? :devil:

but the most dumb statement is that wmv9 has more support on standalones than divx :rolleyes:
man, they should have had a look how many players can already play divx (mpeg-4) and how many handle wmv9, namely not a single one (well ok kiss announced that they will release one) before writing this
but i guess they had most of their info from the m$ homepage anyways...
hm i am pretty sure that billy is promising there "better upcoming device support" :D

also not to speak of that they only used 1pass, which already shows (next to "uncompressed to hd") how much they know about encoding :rolleyes:

[jcsston]

Originally posted by Wilbert
Why didn't they rip the appropriate vob-cells, instead of dumping some decompressed scenes to the hd?
What's worse is that they recompressed the 'uncompressed' clips to Indeo 5.1, clearly they have no idea what they are doing.
These days, encoding video at home is actually more about transcoding (converting from one compressed format to another) than creating an original encode. We therefore took the uncompressed clips and created new "master clips" by encoding them to very high bitrate (around 8 megabit) files using Indeo 5.1 compression, as all our test applications could easily read this format.:eek: