Slashdot Mirror

It was on G... could have done it yourself but, here u are. http://www.compression.ru/vide...

The claim that VP8's inferior isn't a foregone conclusion based on what it doesn't infringe upon.

Maybe not, but there are some clever bits that are locked away by patents so VP8 cannot use them. For example, B-frames. Are you going to claim that B-frames are not useful when trying to encode video?

Also, see the actual results of actual tests.
http://www.compression.ru/video/codec_comparison/h264_2010/vp8_vs_h264.html
https://gist.github.com/Hupotronic/4645784

I know I am not supposed to feed it, but just in case...

Second, When MPEG LA first announced the VP8 pool formation, a rush of companies applied to be in the pool, partly because everyone wanted to see what everyone else had. That gave way to some amount of disappointment. And by 'some amount' I mean 'rather a lot really, more than the MPEG-LA would care to admit.'

Eventually, things whittled down to a few holdouts. Those '11 patent holders' do not assert they have patents that cover the spec. They said '_may_ cover'. The press release itself repeats this. Then these patent holders said 'and we're willing to make that vague threat go away for a little cash'. Google paid the cash. This is what lawyers do.

That's why it's a huge newsworthy deal when companies like NewEgg actually take the more expensive out and litigate a patent. It is always more expensive than settling, even if you'd win the case, and very few companies are willing or able to do it. Google was probably able, but not willing.

As for the quality stuff, WebM is close enough that it doesn't matter. We could argue details of that point, but the real reason Google is doing this is because the use cases for a web-centric codec are VERY different than the use cases for Hollywood and broadcast media. For example, web programmers don't care about encoding speed, we care about battery usage on cell-phones.

The hardware based transcoding is not necessarily better (see: the dire state of BBC's terrestrial HD broadcasts compared to the earlier 'test' HD broadcasts, and their stonewalling whenever people call them out on it and explain how to improve it). Hardware transcoders are used
1) Because they're guaranteed real-time, so you can pipe video through and just factor in a set time delay
2) Designed to be robust, so you don't need to worry about overheating, or the encoder choking on a certain bit of video

If you're not working on real-time video, you're always going to get better results with x.264 (and competence) than with a hardware box, or a hardware solution like QuickSync or the like. Hell, if you turn the quality settings down so the x.264 output looks as bad as QuickSync, the two work at roughly the same speed anyway.

Every...study has shown that the best available VP8 encoders require almost 2x the bitrate of the best H.264 high profile encoders.

Got links?

Sure... this is the most comprehensive qualitative test I've seen, using a huge varietry of sources and metrics. See conclusions section on page 93, which shows WebM requiring >2x the bits of x264 for the same quality.

A rigorous subjective comparison can be found here, using the Double Stimulus Continuous Quality Scale methdololgy.

Note in both subjective and objective comparisons, WebM takes 2x or more bits to achieve the same quality at web bitrates of ~500 kbps.

At much higher bitrates, the quality differences narrow. But high bitrates aren't valuable for Internet use cases, and in any case at 2.5 Mbps and SD resolution, even inefficient codecs like MPEG-2 or WMV8 look good.

So what you're saying is that a format that was only open sourced a few months ago is already within 50% of the quality of one with practically infinite resources behind it, and the best encoder they could find at that.

First of all, x264, the best H.264 encoder, has always been open source. There are hardly infinite resources behind that project.

VP8 quality could potentially improve, but probably not by anything close to 50% while still being VP8. Speed will improve a lot, but quality will likely not improve by a huge margin with the current bitstream. As a point of reference, x264 bitrate/quality ratio has improved by only ~15% in the past four years, after leaping ~25% during the first year of its development. VP8 has been around for much more than a year, and has probably already made its big leaps. A similar development path can likely be traced for other AV codecs, such as MP3, MPEG2, etc.

I've seen tests that rank VP8 as tied with AVC baseline, not inferior by any wide margin.

Nobody uses AVC baseline except for targeting of old-generation iPhones; everything H.264 usually targets high profile level 4.1. And WebM requires 1.5x the bitrate of the best H.264 High Profile encoders for the same quality.

Also since FF cannot include H.264 that means encoding your video in H.264 instead of WebM costs you nearly 40% of users.

Except all (well, 99+% anyway) of those FIrefox users will have Flash installed, or Microsoft's H.264 plug-in. The only thing this move will do is increase the prevalence of Flash. Vorbis was technically better than MP3, and free and open, yet could not supplant MP3 as the standard digital audio format. VP8 is technically inferior to H.264, and the licensing terms and scheme for H.264 are far more reasonable than those for MP3. In short, WebM is going nowhere fast.

If Google was truly interested in an openly specified and freely implementable video standard, they could have simply bought all the H.264 patents from MPEG-LA and freed them. This may not have cost them much more than On2 plus the inevitable patent lawsuits (VP8 may not actually infringe on any H.264 patents, but it is certainly close enough in many respects that there will be more than a few lawsuits.)

Well I learned something new. Perhaps "liberated" would be a better term since the software, like Seamonkey, Songbird, OpenOffice.org, have been liberated from the clutches of single companies (i.e. Microsoft).

Google also has a WebP standard based on VP8, to replace GIFs/JPEGs, but it seems like it's reached a deadend. So WebM is the container.
--- VP8 is the video
--- Vorbis is the audio
Versus h.264:
--- MPEG4 AVC for video
--- plus some audio codec, like MP3 or AAC or HE-AAC

MPEG4/h264 vs. VP8 comparison (h264 slightly better - specially on low bitrate connections):
        - http://compression.ru/video/codec_comparison/h264_2010/vp8_vs_h264.html
HE-AACplus vs. Vorbis (HE-AAC wins):
        - http://listening-tests.hydrogenaudio.org/sebastian/mf-48-1/results.htm
JPEG vs. WebP (WebP wins):
        - http://englishhard.com/2010/10/01/real-world-analysis-of-googles-webp-versus-jpg/

So let's see: WebM is the container.
--- VP8 is the video
--- Vorbis is the audio

Google also has a WebP standard based on VP8, to replace GIFs/JPEGs - wonder why they're not pushing that too? Ya know: Remove image support from their Chrome. (shrug)

MPEG4/h264 vs. VP8 comparison (h264 slightly better - specially on low bitrate connections):
    - http://compression.ru/video/codec_comparison/h264_2010/vp8_vs_h264.html
HE-AACplus vs. Vorbis (HE-AAC wins):
    - http://listening-tests.hydrogenaudio.org/sebastian/mf-48-1/results.htm
JPEG vs. WebP (WebP wins):
    - http://englishhard.com/2010/10/01/real-world-analysis-of-googles-webp-versus-jpg/

MPEG4/h264 vs. VP8 comparison (h264 slightly better): http://compression.ru/video/codec_comparison/h264_2010/vp8_vs_h264.html

HE-AACplus vs. Vorbis (HEAAC wins): http://listening-tests.hydrogenaudio.org/sebastian/mf-48-1/results.htm

WebP vs. JPEG (WebP wins): http://englishhard.com/2010/10/01/real-world-analysis-of-googles-webp-versus-jpg/

Nope, I was referring to this page that I saw last Spring.

Using still images to compare video codec quality makes as much sense as using 0.03-second samples of a song to compare audio quality.

How about this test, which clearly shows VP8 requiring 50% more bitrate to achieve the same objective quality metric.

As far as subjective quality goes, I manage video for an online training site, and we have been evaluating WebM extensively. Even with the most recent 0.9.5 releases, quality at normal web bitrates (say 750kbps for SD) is very inferior to the best H.264 encoders (x264 and Ateme). We did an internal subjective quality survey with our non-technical staff (secretaries, salespeople, etc.) and H.264 won hands-down. We're not interested in increasing our bandwidth bills by 50% to achieve the same quality as H.264, as the licensing fees are very small. Not to mention the browser and device support hassles that currently exist. Oh, and the current WebM toolchain sucks compared with the H.264 ecosystem, but that should improve over time.

By the way, those of you who comare WebM to H.264 using video encoded by Apple's or Adobe's H.264 encoders and say "WebM is almost as good as H.264!" are fooling themselves. The Aplle and Adobe encoders are two of the worst-looking H.264 encoders available.

Ten years ago, one of my friends, who works on movies' restoration and coloring, told me that they had software that was able to remove moving objects from a scene.

The idea was to use the whole scene to recreate the missing parts.

I also remember an article on compression.ru, with plugins able to remove logos or subtitles:
http://compression.ru/video/logo_removal/index_en.html
http://compression.ru/video/subtitles_removal/index_en.html
and even TV ads removal:
http://compression.ru/video/tv_commercial_detector/index_en.html

Ten years ago, one of my friends, who works on movies' restoration and coloring, told me that they had software that was able to remove moving objects from a scene.

The idea was to use the whole scene to recreate the missing parts.

I also remember an article on compression.ru, with plugins able to remove logos or subtitles:
http://compression.ru/video/logo_removal/index_en.html
http://compression.ru/video/subtitles_removal/index_en.html
and even TV ads removal:
http://compression.ru/video/tv_commercial_detector/index_en.html

Ten years ago, one of my friends, who works on movies' restoration and coloring, told me that they had software that was able to remove moving objects from a scene.

The idea was to use the whole scene to recreate the missing parts.

I also remember an article on compression.ru, with plugins able to remove logos or subtitles:
http://compression.ru/video/logo_removal/index_en.html
http://compression.ru/video/subtitles_removal/index_en.html
and even TV ads removal:
http://compression.ru/video/tv_commercial_detector/index_en.html

Probably not. x264 has a number of innate visual advantages to compressing video that were previously mpeg compressed. VP8 generally seems to win on raw uncompressed video in the races I've seen.

Then you've been fooled. The study you're referring to used videos pre-compressed with other MPEG standards, and the VP8 guys claimed that that biased it toward other MPEG-like codecs. They said VP8 got better with an uncompressed source.

VP8 got better. On a single test. A single test is not conclusive for anything but that single test. Note that, even for that single test, it still didn't beat H.264 -- it merely got better.

What we know (not assume), is that the core of VP8 is almost identical to the H.264 Baseline profile. VP8 is an MPEG-like codec! It's got a few small tweaks, some that help and some that don't. The features that would give it an obvious advantage or disadvantage on pre-compressed video are identical.

Does anyone have the comparison site rendering poorly? I am running Firefox 3.6.6 and I can confirm that the site looks awful. Something is surely wrong.

The graphs and the text just below them appear 'cut off' in a way. Anyone experience this as well?

As far as I know, the only H.264 encoder that is regularly superior to x264 is the offering from MainConcept. Read the Fifth Annual MSU Codec comparison, recently published in May 2009.

For quality comparisons, x264 and MainConcept are clearly the best options, with MainConcept slightly ahead. However, on speed, x264 is quite slow. It depends what it more important to you. For me, it's quality and I'll take the speed hit. x264 is truly fighting it out with the commercial products for market leadership.

While the article summary is, strictly speaking, probably correct in stating that "x264 is NOT the best encoder around", it is pretty damn close to being the best H.264 encoder around, and clearly better than its rivals in some areas.

I'm big supporter, and user, of x264, but I always thought MainConcept was the slightly better H.264 codec.

This codec comparison is a year old now, but I've always used these generally yearly tests as a yard stick. MainConcept and X264 are the clear winners, with MainConcept probably slightly ahead overall. If you're short on time, just start reading at page 30.

A detailed comparison of Microsoft's HD Photo with various JPEG 2000 codecs can be found here: http://www.compression.ru/video/codec_comparison/w mp_codecs_comparison_en.html.

Interestingly, it indicates that HD Photo's quality is not particularly better than JPEG 2000 with some implementations of JPEG 2000 significantly outperforming HD Photo.

Well, in English, for Digital Media Net, I've also written an article about the exciting subject of... alpha channels:

http://digitalproducer.digitalmedianet.com/article s/viewarticle.jsp?id=135386

And I'll probably write a couple more, the first of which will be about HDR (high dynamic range) digital imaging. The problem with DMNet is they pay the same for a 3-paragraph article about "how to make your photos sharper in Photoshop" and a 20,000-word article about "how to build a working time machine and fix global warming", so I obviously don't have a big incentive (apart from "educating the masses") to take time off my normal job(s) to write for them.

I've also written a few guides & tips for my DVD site:

http://dvd-hq.info/Compression.html
http://dvd-hq.info/FAQ.html
http://dvd-hq.info/forum

BTW, despite a couple of thousand hits a day and a pretty decent search ranking for the relevant terms, the site has what financial experts call "negative profits". Turns out that educating the masses isn't very good business (even BBC Prime has replaced its "Learning Zone" documentaries with soap operas). On the plus side, I'm pretty sure I'm going to heaven... oh, wait, I'm agnostic. Damn. :-P

I'll probably write a couple of chapters (and do most graphics) for a book about photography that might get published within a year (depends on the main writer), but that'll be in Portuguese, and I doubt it'll ever get translated into English.

As to that JPEG 2000 plug-in, there are pretty big differences in implementation, yes. I don't know j2k, so I really can't say how it ranks. I've been using Luratech's plug-in on the grounds that it was the only one available when I got it. :-) Their browser plug-in is pretty bad, but the compressor seems to be quite good. In this comparison it ranked as the best (for Photoshop), only slightly behind ACDSee's built-in implementation:

http://www.compression.ru/video/codec_comparison/p df/jpeg2000_codec_comparison_en.pdf

Until all browsers (and some digital cameras) come with JPEG 2000 support, I don't see it taking off. Part of the problem lies with the JPEG 2000 specification itself, which is vague about some things, and lacking some basic features (like EXIF, to store camera data). Microsoft's WMP / HDPhoto format is pretty civilized (support for HDR, etc.), but it has somewhat lower quality than JPEG 2000 (it's optimized for speed), and the actual compression and decompression has to be done through Microsoft's APIs. Maybe if they improve it an open-source it (yeah, right), it'll get support from browser and camera makers.

If you want to compare, look here:
http://www.compression.ru/video/codec_comparison/w mp_codecs_comparison_en.html/
a little more info here:
http://forums.dpreview.com/forums/read.asp?forum=1 000&message=21830745/
MS HD Photo is a little better than jpeg, but no better than jpeg2000.
No reason to create a new standard, except to force everyone to use your patents, etc.

Obviously lossless compression is just as good as raw data (in terms of looks, and leaving aside problems such as possible colorspace conversions that a good system won't have). A highend lossless format can compress ~3x smaller then raw http://www.compression.ru/video/codec_comparison/l ossless_codecs_en.html

That being said lossless video is a pain to work with, and honestly most people would rather have more pixels that are, under normal source material coniditions, mostly right, then fewer pixels perfect. Which in the end is always what the choice will come down to. A format that can do HD lossless can do Ultra HDV lossy, the choice for the consumer then becomes rather clear, esp. as humans aren't that that picky about visual stimuli. Though someone will still probably come out with a lossless system, to be bought by people who probably can't tell the difference in normal use (as is the case with high end audio the irony is that the people who are most able to afford it are those least able to see/hear well enough to benefit from it)

MS got flamed for this on digg, and the few posts which are already here do the same, but I'm not so pessimistic about it.

Jpeg sucks, this should be clear to anyone who tried to compare it to Jpeg2000, for example. Unfortunately, J2k seems to be stuck, and since most browsers don't support it by default (even the upcoming IE7 and Opera 9), using this format on web is suicide.

So, if this new format performs at about J2k level, and uses less resources to do so, I'm happy MS introduced it. Due to relative suckiness of jpeg, a lot of space and bandwidth is wasted in everything from cameras to online image galleries. If MS gets the licensing right, it could be a very welcome addition to the image compression methods.

Of course, a stupid/evil license can kill either the format, or whoever tries to use it ;)

http://www.compression.ru/video/codec_comparison/m peg-4_avc_h264_2005/part4.htm

Please look at this H.264 codec comparison. Notice that normal, crappy, unadvanced divx BEATS some of the best H.264 codecs, but we see with the newer H.264 codecs that the new format does provide many advantages, so I'd like to see just how great ffmpeg can get.

You have to understand the industry uses the fastest codec they can get their hands on which is lower than divx mpeg4 quality. Xvid with MPEG4 yields far better quality at present.

BMF may have better compression performance than PNG, but 1. the web site is in Russian (and gives Babel Fish problems) and 2. there's no indication on the translation of the web site that the author is willing to allow reading and writing of BMF images in free software.