Mozilla and Xiph's new Daala video codec to compete with h.265
xiph.org
xiph.org
Daalas goal "is to provide a free to implement, use and distribute digital media format and reference implementation with technical performance superior to h.265."
Wasn't that exactly what Theora was as well?
and now they need a new attempt to get people back on the open codec wagon.
And they have a point: the _screen_, radio, etc. (http://www.ietf.org/mail-archive/web/rtcweb/current/msg03785...) of most mobile devices is already using something like 90+% of the power, so even in the impossible case that hardware accelerators make decode itself use no power they can't make that much of a battery life difference, so long as the device was fast enough to decode in the first place. And this trend will only continue as devices becomes faster and process shrinks lower the computing per joule.
But it's amusing to see some of the same people arguing that hardware accelerators were _must have_ are now arguing the opposite now that its their latest format which is suffering for the lack of them.
Nah, that is simply untrue. Theora was designed in the late _90s_ and targets a different computational envelope than AVC— it's pretty darn good compared to MPEG-2 (or even MPEG4 part-2/DivX) which are more contemporary.
Today there is a much large computational budget available, plus new experience and understanding.
> Nah, that is simply untrue.
Could you provide something to back this up? I cannot find it now, but I seem to recall an x264 developer discussing the difficulties in implementing an open source codec equivalent to or better than H.264 and the problem was mainly due to the fact that all the best algorithms had been patented.
Perhaps if you are a Theora developer (or know one), you can clarify.
(might be the link?)
I am a Theora and Opus developer, although I'm not exactly sure what clarification you'd like.
I can tell you that in my codec experience the patents have seldom (never?) been a major direct barrier to progress by precluding an essential technique... By their nature they tend to not absolutely foreclose anything except outright copying a technique— and even then only in a specific context, and video coding and signal processing are old enough and mathematical enough that the basics are unpatentable. (Keep in mind— the patent office does not believe it allows patenting pure mathematics, their definition of "does not" and "pure mathematics" and mine may not agree, but their evil is finite and thus surmountable)
The impediment from patents seems to most often take the form having to spend time and effort in patent research and negotiations, not being sure that you can just implement some randomly discovered research, erroneously discarding some useful techniques which could be used but isn't worth the effort to clear, and the cost of spending time with attorneys teaching them enough codec engineering— or, frankly, spending time correcting misconceptions on the Internet— rather than coding.
Or in short, _A patent_ is almost never a big problem for a designer, but _the patent system_ wastes a lot of effort by creating big largely non-engineering overheads that sap engineers time and energy. The system also complicates or discourages cooperation by creating odd business motivations and incentives to be secretive (especially about defense strategies). But the non-free codecs suffer from some of these costs and pressures too— plus additional ones like arguing over which winners and losers get their techniques in the format and thus a share of the fees (and access to cross licensing).
This mess also exists just as much outside of media codecs. But the enforcement is less active— I suspect partially because codecs are unusually attractive to monetize due to network effects (switching is MUCH more expensive) and because they make nice attorney-understandable atomic units of infringement that map to visible features. "I own h264, you have h264. Pay up!" works better than "I own computing the absolute value by this series of bit operations. You may or may not do this, I can't tell because of your obfuscated binary. Pay up! Maybe?". The network effect also makes very narrow patents more useful— it's much easier to write a patent that reads on implementations of H.264 (a single format with a fairly exact specification) than one that reads on any format similar to H.264. Very narrow patents are less costly to obtain and enforce (Less risk of invalidation), and the network effect says that you must implement H.264 not almost-H.264 so they are no less good at extracting royalties. But no one really cares if their kernel uses xor-linked-lists or not, and it's usually no compatibility problem to switch if someone starts making threatening noises.
If you were thinking of Jason Garrett-Glaser's early technical analysis of VP8, I don't think he was saying quite what you walked away with... but it's also important to note that Jason didn't (at least at the time) have substantial video coding experience outside of his work on x264 (and some related things in ffmpeg), and didn't have substantial experience working with patents, and had never been involved in a RF codec effort of any kind (including the ones attempted in MPEG). He's "just" a particularly brilliant guy that came in writing assembly code like a force of nature and made x264 much better. To the extent that he could have been emitting the impression that everything in video is patented he would have been just repeating the not-very-well-informed conventional wisdom.
Patent infringement is all about the fine details— so even a patent expert's off-the-cuff comments are going to be somewhat useless. I'd take Jason's thoughts on the latency of PAVGW as the word of God, codec patents, when he'd not even looked at the involved patents? meh. Later revisions of his analysis substantially softened some the remarks, but few people went back to read them. (I recall that I was especially amused by some of the things he derided as being 'unnecessary', as I thought I had a reasonable guess which patents Google/On2 had been specifically dodging).
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.
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.
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.
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.
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.
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.
Clearly Mozilla and Xiph couldn't, in your world, have pulled off an audio codec that blows everything away. Oh, wait, they did!
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.
The preceding comment is false: http://src.chromium.org/viewvc/chrome?view=rev&revision=...
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.
h.264 won over VP8 because VP8 came too late, and it was unfinished and not even that good when Google bought it. By the time Google made it on par with h.264, h.264 already won the format war. But with a new format war coming up soon, and with other codecs like Daala and VP9 being ready to compete (hopefully) from day one, h.265 might not be the default option as h.264 was.
Also I think all new chips that came out this year had hardware acceleration support for VP8, and most media players support it now, too, as well as WebRTC. So even if h.265 wins again, hardware manufacturers may also support at least one of these open source codecs in the future, alongside h.265.
I've seen a lot of speculation that they invested in it mainly to have more leverage when negotiating with the H.264 folk.
Thus I do feel the "relevant XKCD comic" is relevant, even if some find the posting of such comics annoying.
There's no need to replace telnet. There is a need to replace gif wrt animated images.
Unless the Daala people can get some good lobbying, or can make their codec in such a way that minimal effort is required by hardware vendors to support both H.265 and Daala, then I think it's likely to end the same way as previous open video codec attempts.
B) I agree that WebM fits with the XKCD comic because it's doing the same thing as an existing widespread standard but 'ours is more awesome trust us'. But changing hardware and math make a legitimate need for the creation of 265/daala. If 265 was already finished and implemented you could make the XKCD argument, but it's not.
I don't see how you can say the XKCD comic applies to WebM/H264 but can't apply to H265/Daala because they are "proposed standards", and have not yet been implemented. If anything that makes it's specifically applicable to H265/Daala. A proposed standard going against another proposed standard touting benefits the other one doesn't have, but in the end it will probably just muddy the water a little bit.
WebM looked at the landscape of H.264 and tried to be subjectively better. People didn't want to switch, it didn't get anywhere.
H.265 is looking at the landscape of H.264 plus time and better methods/computers and is trying to be objectively better. It objectively uses far less bandwidth for the same quality; it is a generation ahead.
Daala is looking at the landscape of H.264 plus time and better methods/computers and is trying to be objectively better, the same way H.265 is.
H.265 and Daala are equals (as far as I know) in trying to replace obsolete technology. Neither one is trying to be a more friendly/clean/nice replacement at the same level as existing and working standards.
Side note: What is the comic even talking about with character encodings? As far as universal character encodings there's what, three, all of them Unicode? Two if you ignore china? Before that you had a bunch of country-specific pages but they weren't competing. EBCDIC vs. ASCII isn't exactly a plethora either...
You can continue to go on about the march of time, but Daala appears to be getting much inspiration from current gen codecs via the x264 project and WebM.
As far a character encoding, I think you're viewing that problem too simplistically.
http://en.wikipedia.org/wiki/Japanese_language_and_computers
"...most Japanese emails are in JIS encoding and web pages in Shift-JIS and yet mobile phones in Japan usually use some form of Extended Unix Code. If a program fails to determine the encoding scheme employed, it can cause [garbled characters]...", that doesn't mention ISO standard character encodings or Unicode, and that's for Japan alone.
While you may not feel that they are directlycompeting, the fact that they exist mean that are vying for attention from developers and content creators. Legacy cruft will often result in old defunct standards living longer than the people who were creating the new standard expected.
Also the XKCD is meant to be tongue-in-cheek and funny, poking fun at the naivety of the thought process regarding the pursuit of efficiency or improvement. I don't think it's really meant to discourage people.
It distracts from your point that you're comparing a codec to an encoder and a bundle of codecs and container. But either way, why shouldn't a next-gen whatever, learn from the previous gen? Isn't that part of the point?
There is nothing wrong with taking inspiration, and I never said there was anything wrong with it. I mentioned it to note that Dylan16807's suggestion of H265/Daala having no similar use cases or relation to current generation video technology was not really correct.
Theora was supposed to be the unencumbered alternative, then it was VP8 and now it's Daala. Unfortunately, all these and even closed/patented codecs have just muddied the waters rather than being the "alternative" that solves it all.
Getting adoption of codecs is much harder in today's world than it ever was. The online, mobile and browse worlds are so divided than no company would ever want to give another an advantage by adopting the other companies codec.