Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why doesn't Apple just include WebM support? It's an open codec...


Keep in mind Apple devices have HARDWARE h.264 decoders. It may not be as simple as you think.


Hmm true. I wonder how different the hardware decoding is...


Because Apple uses h.264 in all their hardware. They have implementations on firmware so they could accelerate video on their iPhones, iPads, iPods, even making specific hardware for it.

This makes this videos to perform great on their hardware, fast and taking less resources(more battery),it lets them make things like editing video in real time on your phone, but only works for one codec.

If they use software codecs, all their competitive advantages are lost on mobile.


That would imply decoding in software. H.264 is currently decoded in hardware on those devices.


From the bits and pieces that I have read, there are some very real patent questions still looming.

Jason Garett-Glaser put together a great comparison of h.264 vs VP8/WebM. Check it out here: http://x264dev.multimedia.cx/archives/377

His summary: the spec is really terrible, the performance leaves a lot to be desired (though, there is a lot of room for optimization), and it 'copies too much from H.264 for comfort'.


This comment in response to that post makes an interesting point; the most similar bits are likely the most carefully vetted, and may be written deliberately to avoid patent infringement. Patents on standards can be very narrow; as long they cover exactly what's in the spec, then any implementer of the standard still has to pay up:

"Patents are about _details_ so the mere fact that something does something like something else, isn’t necessarily something at all.

As we’ve pointed out before, many codec patents are exceptionally easy to work around: They specify every little detail because it makes it _much_ easier to get through the examination but doesn’t harm the patent’s ability to read on the final standard because the standard specifics exactly the patented behaviour.

D_S, for all his undeniable H.264 experience isn’t an expert on patents or even the H.264 patents. We can assume that in cases where VP8 looks similar to H.264 those would have been exactly the cases where care was taken to differ in the right places. I’d expect the primary risks for VP8 to be anywhere _but_ there."

more at http://blog.gingertech.net/2010/05/20/vp8-adobe-is-the-key-t...


Sorry for the downvote but that was a very early analysis and the story has progressed a bit since. There's room for a more nuanced evaluation of WebM which I'd like to hear.


How do you know whether anything at all has advanced? One of the most knowledgeable authorities on video compression has called into question VP8's patent situation. Why is there any need at all to imagine a false opposite? Other than optimism?

The whole VP8/webm situation reminds me of when Microsoft tried to do the right thing and open-license VC1, but got clobbered by patent holders and had to reverse themselves.


Dark Shakari's latest pronouncement on video encoding patents was to accuse someone of patenting his idea by reading commit logs, and argue at the same time that the idea was obvious to anyone and therefore not patentable. His evidence that it must have been copied? Because it didn't include some later changes he made. (Note this doesn't even pass a basic logic test, never mind constitute a sophisticated take on the current patent situation). He then retracted the accusation.

http://x264dev.multimedia.cx/archives/589

Update: Tandberg claims they came up with the algorithm independently: to be fair, I can actually believe this to some extent, as I think the algorithm is way too obvious to be patented. Of course, they also claim that the algorithm isn’t actually identical, since they don’t want to lose their patent application.

I still don’t trust them, but it’s possible it’s merely bad research (and thus being unaware of prior art) as opposed to anything malicious. Furthermore, word from within their office suggests they’re quite possibly being honest: supposedly the development team does not read x264 code at all. So this might just all be very bad luck.

Regardless, the patent is still complete tripe, and should never have been filed.



My guess is patents. And they already have great H264 implementations. And hardware support.

What would be the benefit, to them or their users, if they used WebM?


Since when has Apple supported open standards simply because it makes sense to do so? Apple almost invariably chooses closed over open.


Apple is fully behind HTML5 - http://www.apple.com/html5/


Yes, in spirit too:

"This demo was designed with the latest web standards supported by Safari. If you’d like to experience this demo, simply download Safari. It’s free for Mac and PC, and it only takes a few minutes."

Come see web standards! Using a specific browser.


Hum, because they're showing the latest HTML features that Safari supports? Not all browsers support the same range of features for a particular HTML standard.


A couple of days later, I found this: How much HTML5 is there in Apple's HTML5 demos? http://blog.marcoos.com/2010/06/09/is-html5-by-apple-really-...


Any organization which denies access to its HTML5 pages to browsers that support them is not fully behind the spirit of HTML. The reason is clear and understandable — marketing their browser — but so are the implications.


Yet the number one reason there isn't a codec specified in HTML5 is because Apple blocked it.


Bullshit.

Multiple companies, including Apple (and Nokia, which ain't exactly a minor player in the mobile market) objected to HTML5 mandating support for a particular codec, largely on the grounds that we don't really know the patent situations of any of the allegedly-unencumbered codecs.

Meanwhile, multiple people objected on the grounds that mandating a current (or, really, several-years-old now since that's what it is) codec in a spec that's not expected to go final for at least a few more years, and which has an expected useful life of around a decade, is just frankly stupid. It'd be like having a spec used today mandate XBM as the standard image format because that was the least-proprietary thing available 15 years ago when early browsers were being written.


Multiple companies, including Apple (and Nokia, which ain't exactly a minor player in the mobile market) objected to HTML5 mandating support for a particular codec, largely on the grounds that we don't really know the patent situations of any of the allegedly-unencumbered codecs.

Now it's my turn to call bullshit. "We don't really know the patent situations of $x" could be used as an argument against ANY piece of software or standard $x. Unless there is real evidence for such concerns, it's FUD.


There ain't no such thing as a free codec. At least, not as long as software patents exist.

Does Google want a Free, interoperable web? Then they should take the money they'd spend re-encoding all of YouTube into VP8 and instead spend it on lobbying to eliminate software patents. Then they could just use whatever's the best option from a technical perspective and we could stop having codec shitstorms every six months.


"There ain't no such thing as a free codec."

This is what groups like the MPEG-LA want us to think, but I'm not so sure. The Ogg Vorbis codec used for WebM audio has been in use for a decade, and has shipped in dozens of software and hardware products, some from large companies with big pockets. MPEG-LA made the same vague threats about patent pools against Vorbis, but they never followed through.

Xiph.org conducted a patent search early in the Vorbis process, and believes Vorbis does not infringe on any patents. Google has done their homework on VP8 as well. If they did it right, then VP8 is no more vulnerable to unknown patent threats than any random piece of software. (Sadly, any random piece of software is somewhat vulnerable.)

For that matter, there's no guarantee that H.264 is invulnerable from patent trolls who aren't members of the licensing pool. MPEG-LA doesn't indemnify licensees against third-party patents.


Sadly, any random piece of software is somewhat vulnerable.

Any random piece of software is vulnerable.

Look, if Google's serious about the threat software patents pose to openness, there's an obvious thing they should be doing, and it isn't "switch the video codec we use in our web browser". Until I see them doing some serious (i.e., big-money) lobbying to abolish software patents, I'm going to assume the whole openness thing is just marketing bullshit designed to play into geeks' stereotypes of them and Apple.


Not that I disagree, but a "patent search" early in the process for Vorbis is not that comforting. Vorbis has been around for a while now and new patents are awarded that all the time that are used against prior art. Unless Google/On2 has an inside man at the patent office raising Vorbis as prior art, it's likely that someone could craft a patent specifically intended to target Vorbis, get it approved, and then sue lots of people. Trolls take this approach fairly often.


Also, Apple used to be fully behind royalty-free standards for the web:

http://lists.w3.org/Archives/Public/www-patentpolicy-comment...

Apple believes that it is essential to continued interoperability and development of the Web that fundamental W3C standards be available on a royalty-free basis. In line with the W3C's mission to "lead the Web to its full potential," Apple supports a W3C patent policy with an immutable commitment to royalty-free licensing for fundamental Web standards. Apple offers this statement in support of its position.

It's powerful and persuasive stuff, worth reading in full. They only removed this statement from their website about 6 months ago.


Have they said or done something that conflicts with this statement?


Their implementations of the HTML5 <video> and <audio> draft standards work only with royalty-encumbered codecs. (The licensing is currently royalty-free for publishers and end users, but not for device manufacturers or browser vendors.)


Have they ever proposed that those codecs be part of the standard?


Google were also opposed to a format in the spec, they claimed ogg theora was too large in file size. Why do you think they bought On2 and released WebM in the first place? There already was a free video code theora before.


That's false. Read this: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-Jun...

MS didn't commmit to anything, Mozilla essentially blocked H.264 from becoming specified codec too. All had reasonably sound reasons to hold their respective position. Not everything can be explained as good vs. evil.


You call this being "fully behind HTML5"? http://grab.by/grabs/0b694089e83975c385627b134ee8ece7.png

Even Microsoft's better than this.

edit: could whoever downvoted me explain why he did so?


That's not inconsistent with being "fully behind HTML5". That page is meant to show off how Safari handles various HTML5 features. If you view it in a different browser, it is not showing you how Safari handles those features. Hence, it makes perfect sense for it to try to limit itself to people using Safari.


That page is meant to show off how Safari handles various HTML5 features.

Isn't the point of HTML that all browsers handle it similarly? If that link is restricted to one browser, it isn't better than all the "Designed for IE6" sites you used to see in the early '00s, and absolutely no evidence of Apple being "fully behind HTML5".


HTML5 is not a standard. It does not yet behave the same in all browsers that implement it. Different browsers implement different subsets of it.

The site you cite is meant specifically to show how Apple is doing with their HTML5 implementation. There is simply no point in viewing it in another browser. Viewing it in, say, Firefox would tell you nothing at all about how well Apple has implemented HTML5 in Safari.

This is completely different from the "Designed for IE6" sites. Those sites were generally presenting information that was useful to people regardless of which browser they were using.


HTML5 is not a standard. It does not yet behave the same in all browsers that implement it. Different browsers implement different subsets of it.

And yet they're converging to implementing all of it.

The site you cite is meant specifically to show how Apple is doing with their HTML5 implementation.

Then it's a Safari demo, not an HTML5 demo. The Microsoft demos use HTML5 and yet work just fine in other browsers.

Those sites were generally presenting information that was useful to people regardless of which browser they were using.

How is seeing HTML5 working in Firefox or Chrome not useful to people?


> Then it's a Safari demo, not an HTML5 demo.

Correct, which is probably why Apple says: "The demos below show how the latest version of Apple’s Safari web browser, new Macs, and new Apple mobile devices all support the capabilities of HTML5, CSS3, and JavaScript".


I love to hate on Apple's decisions, but this is just ludicrous.


Comment of the year right here, folks. +4 already too. Thank heavens its a throwaway, how embarrassing.


It's not exactly insightful but it does have some merit. Apple's approach is an odd mix of open and closed. You could describe it as 'strategically open'... (of course - this applies to Google too to a slightly lesser degree).

No company supports open-source if it directly conflicts with their perceived interests. Some companies just take a wider view than others.


I'd like to see a compiled list of open technologies Apple has chosen vs closed. "invariably closed" my arse.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: