Item — HN Reader

Well it is not very new as it has been discussed for a while. But at least now more people knows about it.

But as the recent Reference Implementation has shown H.265 is moving ahead faster then the previous H.264 has happened. Its quality is already quite good, and many manufacturers are ready to show their Encoder and Decoder in CES.

So for both Software and Hardware Encoder, they are waiting for the final draft and final validation before making them for sale.

VP9 is finally shaping up to be good. VP8 was never up to x.264 encoder standard. At least VP9 is making some quality improvement. But most of the current VP9 material just reads like marketing BS.

While i would love to see Daala, or a codec from Mozilla rather then Google to succeed. It is just not going to happen. Mozilla has never been known for fast moving, and the amount of engineering required for a Video Codec is just huge. Even Google couldn't pull it off. And i doubt Mozilla can. Since Daala is still in research stage and it would take at least 2 year before anything done. By the time H.265 is already well ahead.

2 comments

> While i would love to see Daala, or a codec from Mozilla rather then Google to succeed. It is just not going to happen. Mozilla has never been known for fast moving, and the amount of engineering required for a Video Codec is just huge.

Clearly Mozilla and Xiph couldn't, in your world, have pulled off an audio codec that blows everything away. Oh, wait, they did!

http://www.opus-codec.org/comparison/

Worth noting they also got Opus standardized through the IETF[1] and, furthermore, it's mandatory to implement in the WebRTC spec[2]. So Opus is not only technically superior to other audio codecs, it's also better situated politically than Xiph.org's past efforts (eg. Vorbis, which sounds great but never really achieved relevance).

[1] https://tools.ietf.org/html/rfc6716

[2] http://jmspeex.livejournal.com/11042.html

I can't encode my video files or music with Opus because you can't arbitrarily seek the track without backing up around 80ms and playing back up to the point where I want. So it isn't available in webm containers yet for that reason.

It won't be in "webm" because WebM is a very narrowly defined profile of MKV+Vorbis+VP8 (which is important for compatibility), and Google already made a decision to not use Opus in "WebM" to avoid confusion.

Perhaps you instead meant MKV? (now responding to the comment on frames/MP3) Yes. That is an issue for MKV with Opus. The problem is that the MKV container has no mechanism to signal a stream level or seeking level preroll other than just having frame boundaries. With Opus you need to seek several frames back and decode forward (not just a single frame) in order to converge. This isn't unique to Opus: Various video formats can be encoded with rolling intra (e.g. H.264) a mode which is useful for conferencing because it avoids fat keyframes. Since the movie 'backup' scene doesn't encode this way the mkv ecosystem's solution to these sorts of streams appears to be, so far, to fail to seek in them. I'm sure it will get worked out eventually.

-- It won't be in "webm" because WebM is a very narrowly defined profile of MKV+Vorbis+VP8 (which is important for compatibility), and Google already made a decision to not use Opus in "WebM" to avoid confusion. --

The preceding comment is false: http://src.chromium.org/viewvc/chrome?view=rev&revision=...

The same is true for seeking in MP3, FYI. You can only 'seek' to a specific frame in the file, and frames have a fixed length. Sub-frame seeking in MP3 only came later and it works the same way - seeking to the nearest frame, and then discarding some audio to get to the desired point.

I would be interested to know why that is a blocker for you. For media consumption, at least as I normally practice it, that sounds like a detail I'd only notice by reading the code rather than perceiving it in the audio.

It isn't blocking me, but it is blocking wider adoption. I'm not really an audiophile that fine tweaks my encoder settings per file, so trying to convert with the opus library is grating, but it doesn't really have any mainstream encoder support yet (it is experimental in ffmpeg).

>Clearly Mozilla and Xiph couldn't, in your world, have pulled off an audio codec that blows everything away. Oh, wait, they did!

Clearly, in your misplaced sarcasm, you didn't read what he wrote. He didn't say anything about Mozilla being unable to write a codec that "blows everything away".

He wrote that Mozilla couldn't make that codec a _successful standard_. And, oh wait, they did not.

Even Opus (re: WebRTC) is a standard, but not successful at all, and it probably would not go anywhere.

Oh, and I would take the BS marketing page from Opus with a grain of salt, too, re: blowing everything away.

I wonder why they feel the need to create a completely new open source video codec, though. Can't they just collaborate with Google on VP9? Or is their technology fundamentally different? Or maybe they think Google is controlling VP9 development more than they should. Was it a technical or political decision?

This is basically the same way that standards like H.264 get developed. A bunch of people have good ideas, make reference implementations, and get together and choose one (or mix and match). If you skip the last step, you end up with multiple standards instead of one. Which is fine. It's less work.

See: http://x264dev.multimedia.cx/archives/360

I don't think there's a problem with creating new codecs. It's not that rare to get new codecs, and there are a lot of good reasons to create new codecs. Besides codecs like H.264, Theora, and VP8, there are also ones like FFV1, Dirac, Snow, Apple ProRes, and Apple Intermediate Codec. These can fill specific needs not met by H.264 or they can be used for research.

However, that's not all. VP8 was a bit of a mess when it was released. I'm sure VP9 will be better, but the VP8 spec was little more than a reference implementation. Bugs in the reference implementation therefore get baked into the spec. Xiph.org has more experience producing viable compression specs than Google, so if I were them, I wouldn't camp out under the Google brand if I were making a new video codec.

If anything, we should be asking why Google didn't just collaborate with Xiph for VP8. That's not to say Xiph hasn't screwed some things up too, like the Ogg container format, but at least they make it easier on people writing competing implementations.

I'd rather ask why Google didn't make vp8 defacto on youtube instead of adopting h.264, let the Apple mobile devices flounder without support, and push really hard on Android manufacturers to hardware accelerate vp8 (or 9 now). They could have taken over the online video market, and gotten webm as the video tag standard easily. Instead the last 5 years played out in a battle of attrition because nobody actually uses webm media excusively the way big media uses h264.

YouTube is a profit center for Google, VP8 is a delivery mechanism for YouTube. Google has already taken over the online video market with their purchase of YouTube, I doubt that sacrificing YouTube for a bigger share of the codec pie is really worth it to Google.

Instead they can play the long game. VP8 support can make its way into browsers and hardware, and by funding alternative codecs (increasing supply) they can keep the licensing costs for H.264 and its successors down. It's easy to speculate that if H.264 were the only game in town it would probably be more expensive.

I don't know what you mean by "battle of attrition". Current state of affairs is that we have some good, free codecs; some better, inexpensive codecs; and improvements are on the horizon in licensing, software support, hardware acceleration, and codec sophistication.

> they can keep the licensing costs for H.264 and its successors down. It's easy to speculate that if H.264 were the only game in town it would probably be more expensive

That isn't even a very speculative speculation. The release of Vorbis triggered clear drops in the MP3 licensing costs— at a time when there seemed to be no other reason to drop the prices.

Strategically, one major methods of success for royalty free codecs is simply to keep driving the— otherwise monopoly-class— profits out of the non-free codec space. They don't have to be the #1 choice to achieve this, just enough of a threat with enough installed base that the marginal cost of switching is kept low enough to present a real ceiling on the price of the non-free stuff. (Though the wider the adoption and the more competitive the harder and lower the price ceiling it creates)

Especially once you factor in all the disadvantages royalty bearing codecs have: Overheads from profit motivated engineering decisions, the need to constantly cannibalize the last generations revenue stream to keep the installed base on the 20-year patent expiration hamster wheel, the non-trivial base of users that just want something that works and is easy to integrate who don't like having to apply and pay for licenses and track and report usage quantities, etc… it's pretty clear that the RF side will eventually win this fight so long as they keep cracking away at it.

The only real question is how long and how many billions extra will the public pay before we get to that eventual outcome.

Apple and Microsoft were never going to allow vp8 in the html spec. What Google should have done is press vp8 more on the web and not left Mozilla floating in the breeze.

However, Google only purchased on2 in 2010, and hardware support has actually spread remarkably quickly for that amount of time, probably because they've been pushing it on Android. A bunch of current devices support hardware vp8 encode and decode and, in a year or so, it will likely be difficult to buy an android device without support.

IMHO, the main purpose of VP8 was as a bargaining chip to prevent MPEG LA from doing anything particularly onerous with their licensing. Seems to have worked.

>I'd rather ask why Google didn't make vp8 defacto on youtube instead of adopting h.264, let the Apple mobile devices flounder without support, and push really hard on Android manufacturers to hardware accelerate vp8 (or 9 now).

Google makes money on ads. Including on YouTube.

Now, Android doesn't make Google any money. It's a long term bet to have a foot on the mobile space. Including the Motorola acquisition --and giving it for free--, Google has most likely LOST money on Android thus far.

Plus, Android doesn't have much presence in the mobile web. Despite outnumbering iOS devices, Android devices produce far less mobile web visits. Probably because lots of them are sold to the lowest consumer tier, free with a contract, that is, to people that don't care about the "mobile web" thing much at all.

So, Google pushing VP8 on YouTube / mobile would just serve to cut Google from the mobile advertising pie, which is largely iOS.

And it's not like Apple, if pushed, couldn't have added some basic flash player capability, even if only for video support. Adobe, for one, would have jumped at the chance to give it to iOS.