I hope Daala will put an end to this mess. But even though Opus is mandatory now, it didn't yet translate into support by Apple and MS for instance for regular music and Web audio. Their historic sickening opposition to open codecs is not easy to dismantle. Apple still doesn't even support FLAC, just because they like to make things messy for everyone.
By the way, what happened with Nokia's attacks on VP8? Were they refuted by Google or they were validated by some courts?
TL/DR: VP8 was found not to infringe one patent. The other proceeding in the German courts was stayed until it was determined if the patent was valid. Before that could happen, Nokia and HTC settled all of their outstanding suits for some undisclosed amount. All remaining actions between those two parties were dismissed without prejudice (including the VP8 lawsuits). Separately, Google is still proceeding with two lawsuits in Germany to get the Nokia patents declared invalid.
Despite the gazillions of dollars they have earned, Apple is really constrained when it comes to software development.
They don't have the man power to stray far from their focused feature set. Just look at the mess that iOS 8.0 is. I don't know if they are not willing to hire more capable people or if they just don't care as long as the money pours in (that could bite them in the long term though).
FLAC is a niche feature and those features are usually only supported if someone at Apple has a personal interest in supporting it and if it doesn't get vetoed by the power that be.
In the case of FLAC it might even have been the latter as you could describe FLAC (not entirely correct) as the codec that let's you digitize your CDs losslessly. That view would put it in competition with iTunes (320kps AAC/MP3 ought to be enough for anybody?) and additionally, if you are a true Apple follower, you don't have a CD drive anymore anyway.
> That view would put it in competition with iTunes (320kps AAC/MP3 ought to be enough for anybody?)
Apple has its own lossless audio codec that's supported by iTunes called ALAC. Created in 2004, it was initially propriety but as of 2011 it is now open source and royalty free under the Apache License.
No idea why you're getting downvoted, we use ALAC in production workflows. Prior to being open sourced it was also successfully reverse engineered in 2005: http://craz.net/programs/itunes/alac.html
> Their historic sickening opposition to open codecs
What are you talking about? I'm not aware of any historic opposition to open codecs at Apple. Hell, they're still big into AAC, which is an open codec. And even ALAC is now open source and royalty-free.
AAC is pay for use codec and Apple receives royalties for its use through MPEG-LA. ALAC was historically proprietary, it was opened only after it lost to FLAC. Apple never supported any codec, that was really free, like Vorbis or FLAC.
There's been plenty of detailed reports concluding for the small number of patent Apple holds, they don't receive anywhere near enough money to cover their own MPEG-LA fees. They aren't doing this out of financial interest — it simply isn't worth enough to them to justify that.
That does not matter, from financial perspective they still pay less, than any non-member of the MPEG-LA would, say Debian or Mozilla.
It also provides them a bit of control over potential competition, that they would not have with really open codec. They also make it inconvenient from licensing/business model to use in some projects, see what trouble these codecs cause to projects like Mozilla/Opera, Linux distributions, XBMC, VLC etc, which does hamper them significantly.
The far bigger financial advantage for them is the fact that they hit the maximum fee — so they end up paying comparably little per user.
I'm not sure Apple is even that concerned about the competition from such projects — all their major competitors have no issue with paying the licensing charges.
It's worthwhile pointing out that Mozilla nowadays use H.264/AAC/MP3 support from the platform layer, as does Opera (though, yes, most Linux distributions do not ship such things by default — but that's a small percentage of the market) — and in Opera's case the argument to not support it was always one of philosophy (avoiding giving themselves a competitive advantage that works against a free and open web) rather than one of finance (Opera has plenty of revenue to pay for the license).
When there were all the discussions around HTML5 and mandated video codecs the reasons that Apple publicly put forward seem reasonable from their point-of-view: supporting video codecs that no major company has previously shipped bears a risk of patent infringement cases (and defending such cases is expensive, even if your odds of winning them are good!) that might result in huge fines/compensation. When the majority of the content on the web was already using H.264 (and it seemed dubious that many sites would support more than just H.264 unless everyone dropped H.264 support, which seemed highly unlikely to happen), there was no compelling market reason to take on that risk. The de-facto state was the web already relied on a non-free codec, and mandating a free one was only of marginal benefit if nobody started using it (yes, it provides a free common baseline, but de-facto everyone has to support H.264 as a baseline anyway, however sad that is). This isn't so malicious as it is accepting the reality of the market, sadly.
When almost all browser installs support H.264 already, you may as well use it for WebRTC. Would it be nice if the web didn't rely on H.264? Yes. But we're already at a point of relying on it, so we may as well rely on it elsewhere.
> And even ALAC is now open source and royalty-free.
Nothing stops them from supporting FLAC as well except their nasty attitude in general. FLAC is actually used by many services which sell music, unlike ALAC.
>Nothing stops Mozilla from supporting JPEG2000 except their nasty attitude in general. JPEG2000 is actually supported by many image editors, unlike APNG.
I think in most of these cases the real reasons are more mundane - spending the resources on supporting extra formats would give them no competitive advantage (and a significant cost in terms of maintenance and security). It sucks, but that's the capitalist system for you.
That analogy seems to ignore that FLAC is literally the lossless format that is used everywhere - except on Apple devices, and has not and never had patent concerns. On top of that, ALAC is clearly based on FLAC but has effectively been worsened. It is pure and 100% literal NIH. The same can't be said for JPEG2000. Not even close.
Nobody's complaining Apple doesn't support actual MPEG ALS, for example.
Supported everywhere != used everywhere. In my experience, extremely few people use FLAC, because there's almost never a reason to care about having a lossless audio codec. I'm pretty sure I've seen FLAC mentioned by people coming up with reasons to complain about Apple several orders of magnitude more times than I've actually seen FLAC in the wild.
>Patents stop them (JPEG2000 is not a free format).
Oh please, stop with this FUD. JPEG2000 is no different to Ogg or VP8 in that regard, both of which Mozilla is happy to ship. It was designed to be usable without having to licence any patents. Any known patents have been waived. The possibility of unknown patents remains but is vanishingly small by this point (other organisations much larger than Mozilla have been shipping JPEG2000 code for years).
>Furthermore, it includes guidelines and examples, a bibliography of technical references, and a list of companies from whom patent statements have been received by ISO. JPEG 2000 was developed with the intention that Part 1 could be implemented without the payment of licence fees or royalties, and identified patent holders have waived their rights toward this end. However, the JPEG committee cannot make a formal guarantee, and it remains the responsibility of the implementer to ensure that no patents are infringed.
What the fuck does Mozilla even mean by "free format" these days? It's an ISO standard, it was designed to be usable without paying any fees, there is a waiver of any known patents, it's been used across the industry for years without legal problems. I can't think of a single way that it could be made "more free". The only possible reason I can see is that it wasn't invented by Mozilla/Xiph. And really that is just pathetic and very much a "nasty attitude".
I can't decide if you genuinely believe that Apple is deciding not to spend resources supporting FLAC because you think they have a "nasty attitude", or if you're deliberately misrepresenting the reasons that lead to such a decision.
Supporting FLAC requires investing engineer resources in doing this, and possibly legal resources as well. It's only something that Apple would do if there's any benefit to them doing it. And there doesn't really seem to be any benefit toward it. None of Apple's hardware supports FLAC natively, so adding support to SO X would actually be rather counterproductive as anyone using it would have to transcode it to some other format to get power-efficient decoding support on mobile devices anyway. And Apple's already had their own lossless compression codec (ALAC) for over a decade. Pretty much the only benefit to supporting FLAC natively would be to make things very slightly easier for the 0.0001% of their customers that acquire music in the FLAC format.
> Supporting FLAC requires investing engineer resources in doing this, and possibly legal resources as well. It's only something that Apple would do if there's any benefit to them doing it.
FLAC is patent free and actively used (commercially including) by many parties big and small, so this legal FUD is totally unconvincing. ALAC isn't supported in hardware any better than FLAC, so that argument completely misses the point.
> Apple's already had their own lossless compression codec (ALAC) for over a decade
And for over than a decade "couldn't find resources" to support FLAC which is actually used unlike ALAC. Poor, poor Apple.
> And for over than a decade "couldn't find resources" to support FLAC which is actually used unlike ALAC.
Are you really this uninformed, or do you just like to make things up when the facts don't go your way?
ALAC was created for the purpose of streaming audio between Apple devices. I believe it was first used to stream audio to an AirPort Express (which has audio output, so you can plug a speaker into it and stream music from iTunes to that speaker). I assume it's still used for that purpose, but it's also used for the more general category of streaming audio over AirPlay. Given that, I would wager that ALAC is used many orders of magnitude more than FLAC is, even if it's not directly exposed to the end user.
Yes, free codecs probably would be a better term. Open here refers not just to the availability of open source tools, but them being open for entry for any participant (including for example projects and individuals who can't pay any license fees).
A WebRTC-compatible endpoint must be able to communicate with a WebRTC endpoint, but apparently need not understand it, at least that is what I make of it.
WebRTC-compatible are things that do not implement the Javascript API. These include things like single-purpose smartphone apps. A "WebRTC doorbell" was an example given at the IETF.
With this proposal, any WebRTC-compatible device can communicate with any browser with video.
These are video codecs. Presumably an audio-only app (e.g. IP phone) would be compatible too, so that would explain using neither of the two video codecs. WebRTC also has datachannels that use neither audio nor video.
This was already-existing terminology in the IETF working-group. A "WebRTC-compatible" device is one that does not conform to the standard, but which can talk to something that does conform to the standard )in whatever limited way it supports). By definition no codec requirements can be placed on it. This was spelled out clearly in the original proposal: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432...
I'm reading that as WebRTC endpoints have to implement those two, but there's nothing precluding them from negotiating to use H.265 or Sorenson or Mpeg-1.
I came in this thread to say that Microsoft are implementing WebRTC, but when I double checked it looks like it's more complicated than that. There's an API that they want, and may have gotten into the spec called the Object RTC API, but they aren't currently planning on implementing WebRTC as existing browsers speak it: https://status.modern.ie/webrtcobjectrtcapi
I think the plan is for Microsoft to ship Object RTC API in IE, and then to ship some sort of a polyfill on top of that that lets you talk to WebRTC over Object RTC.
I saw it long coming. We were butting head at the IETF 88 in Vancouver last year, and following the various correspondences on the mailing list, I knew we needed to make a compromise.
Implementers won't be able to call themselves WebRTC implementations. This specification is referenced by corresponding 3GPP specifications, so compliance there will be more strongly enforced.
It's only the fallback "mandatory-to-implement" codecs they're talking about. If two devices can speak vp9/h265 or others not yet invented, they can use those instead.
I don't really agree with the author's comment that this is "an unmitigated win for users": if nothing else, hardware products might become more expensive because they will need native encoding/decoding capability for each codec.
Most hardware decoders are microcoded anyway, supporting H.264, ASP, and VC-1. Adding VP8 isn't that bad - Qualcomm, nVidia, and Mediatek already ship VP8 decoders.
The next generation codecs such as HEVC and VP9 are a lot more computationally expensive and do require a lot more die area.
It would be perfectly possible for a browser to support H264 high profile in WebRTC and refuse to decode it in a <video> tag, for example due to licensing restrictions, so what you're saying is irrelevant.
I thought the licensing thing is not an issue if you switch to x264 (open source)? Better video also - smaller file size, less artifacts, doesn't desaturate the image.
By the way, what happened with Nokia's attacks on VP8? Were they refuted by Google or they were validated by some courts?