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.
Yeah, the audio case is arguably far more interesting (enough major companies have shipped Vorbis and Speex that it is likely anyone holding a patent would've sued someone by now). One may speculate that by the time the iTunes Music Store launched (2003) they felt locked in to the set of codecs the iPod (launched 2001) supported natively (the CPU in it is weak, and while it is powerful enough for a modern, highly optimised Vorbis implementation, these didn't yet exist, and one must question running the CPU at almost total utilisation for heat/battery reasons…).
Well, what happened in the past doesn't really explain why they still refuse to support them today. I really hope mandatory status of Opus in WebRTC will push it into QuickTime framework and it will mean implicit support by Apple everywhere.
They refuse to support them today because there's no benefit in doing so. Supporting codecs they're not supporting today takes both non-trivial engineering resources, but may expose them to patent risk depending on the codec in question. And pretty much by definition, the people who use these codecs aren't Apple customers anyway.
You seem to be arguing with the assumption that Apple could support these codecs effectively for free, and have deliberately chosen not to do out of malice. That's quite absurd.
> They refuse to support them today because there's no benefit in doing so
That's nonsense. Clear benefit is supporting codecs which their users can encounter without forcing them to reencode to anything else. For instance, you buy some music in FLAC and can use it, rather than reencoding it first. I.e. interoperability and treating users well, rather than being jerks.
Clearly for Apple "benefit" means screwing users and degrading interoperability.
> Supporting codecs they're not supporting today takes both non-trivial engineering resources, but may expose them to patent risk depending on the codec in question
False pretenses to hide real intentions - retaining lock in and reducing interoperability, which were always Apple's notable goals. Specifcially about patent risks - they are already using a bunch of codecs like AAC, so obviously they aren't concerned about risks when using them. So they can't claim they are more scared with other codecs especially if they are explicitly patent free.
> Clear benefit is supporting codecs which their users can encounter without forcing them to reencode to anything else.
That assumes their users actually ever encounter such music. I fully expect that significantly less than 1% of Apple customers ever encounter FLAC music, and those that do, do so infrequently and with other options made available as well. Personally, every time I've seen FLAC as an option, it's been one of a set of options (typically including MP3 and AAC, and often even including ALAC).
> Clearly for Apple "benefit" means screwing users and degrading interoperability.
Bullshit. Nobody is being screwed here. Anyone who gets FLAC music is choosing to do so, and it's pretty trivial to reencode. And there is absolutely no interoperability issue here. FLAC is not a codec chosen for portability reasons; very few people have any reason to be using lossless audio to begin with.
> False pretenses to hide real intentions - retaining lock in and reducing interoperability, which were always Apple's notable goals
Bullshit, bullshit, and more bullshit. Apple was at the forefront of pushing to remove DRM on music, and you're trying to accuse them of lock-in? Either you're horribly deluded, or you have your own anti-Apple agenda that you're trying to push here. Either way, you're pulling this argument from thin air and it is entirely incorrect.
> That assumes their users actually ever encounter such music.
Not "their users", any users. FLAC is the only lossless format that's being actively used commercially (and not commercially) by various services and stores. So, their users encounter it as well when they deal with lossless audio.
> Anyone who gets FLAC music is choosing to do so
Yep, since it's the only practical lossless format offered as above. And Apple chose not to support it to screw their users.
> and it's pretty trivial to reencode.
Yep, it's not hard to reencode. Supporting it isn't hard either - all decent players do it (like VLC and etc.). Apple's one isn't decent though, it's crippled by design, with excuse that "it's easy to reencode". User friendliness just shines there.
A cynic would point out that anyone who is purchasing FLAC music is, by definition, not purchasing from the iTunes Store, so there is very little business reason to facilitate this behavior.
A more practical person would say that nearly everyone who does purchase from an alternative store doesn't want FLAC anyway (or at least, shouldn't want it, though it would not surprise me to see a lot of people who opt for FLAC do so because they think it's a good thing when they really get no benefit from doing so). Very few people ever need to reencode their music these days. Back when MP3 was new and newer encoders kept coming out that got better results, it made more sense, but these days high bit-rate MP3 or medium bit-rate AAC is more than sufficient for effectively all personal uses. Given that, users who purchase from alternative stores would be best served by picking a lossy format that is compatible with their software/hardware (e.g. for Apple users that's AAC if it's provided, or MP3 if not).
For those vanishingly small number of people who have an actual use for FLAC and who wish to play their music on Apple products, it's not very difficult to transcode it to a format that is supported by Apple products. They should be transcoding it for personal usage anyway, because there's no need to be carrying around unnecessarily large files on mobile devices or on laptops. Keep the FLAC somewhere safe if you think you'll actually need it again, and transcode to a more appropriate format. Or better yet, just download the appropriate format to begin with (most independent stores I've seen that offer multiple formats let you download in all the formats you want to instead of forcing you to pick).
> Yep, since it's the only practical lossless format offered as above. And Apple chose not to support it to screw their users.
You do realize that your repeated assertions that Apple is intentionally choosing not to support FLAC out of some personified desire to screw their users is ridiculous, right? I don't know why you keep claiming this. Even if you want to personify Apple instead of treating them like a company that makes decisions that are in the best interests of the company, it's absurd to claim Apple is trying to screw its users.
But beyond that, you keep claiming FLAC is "the only practical lossless format". And yet by your own argument it's impractical, since it's not supported on the hardware/software combination you want.
> For those vanishingly small number of people who have an actual use for FLAC
This approach of dumbifying users to brainless consumers of content is extremely annoying. I consider any company that treats all users that way to be simply insulting. I don't mean those who cater for non technical users and being very user friendly. I welcome that. I mean those who proclaim that they can cripple functionality of what already exists with their justification that all users are dumb and would never need it.
For instance, audio CDs offer two features - good quality of sound and lossless data (i.e. which you can reencode to any lossy format with transparency without degrading quality). Those features are there for years already. Now, comes the digital age and normal services offer a substitute - FLAC. Comes Apple and says - users are dumb, no one needs that functionality. No CDs for you, and no lossless audio either. Take our AAC, and if you want to reencode - get lost.
Well, that's insulting. But Apple aren't alone in it. For instance you can't buy FLAC on Amazon either. On the other hand, other services respect their users more and give an option of lossless audio. Just because they can and it's easy to provide. See Cdbaby, Bandcamd and etc. They offer FLAC files along with a variety of lossy codecs. But this isn't even so much about sellers. We are talking about support in players / systems. One should be a jerk not to provide support when one can treat users with more respect and simply add that support for most common lossless codec.
> assertions that Apple is intentionally choosing not to support FLAC out of some personified desire to screw their users is ridiculous, right?
I see no valid reason for them not to support it, when their own users asked them multiple times to do it. Apple dismissed them. So they do want to screw their users. Or may be simply their dislike of free codecs is stronger than their interest to help their own users. I honestly see no single valid reason for them not to do it, especially since it's trivial. It's available in every possible third party player imaginable. But Apple? No, they pretend it doesn't exist.
> 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.
> Supported everywhere != used everywhere. In my experience, extremely few people use FLAC,
Way more than ALAC. Music in FLAC is provided by many music services and digital stores. Music in ALAC? I never saw it being sold anywhere.
> because there's almost never a reason to care about having a lossless audio codec.
That's utter nonsense. Any time you want to reencode your music, you care about the lossless codec for the source, otherwise you'll degrade your quality. For example if tomorrow some state of the art lossy codec comes out which reduces size / computational complexity of decoding (such as Opus for instance), you can reencode your audio library in it for usage in mobile devices and so on. But without lossless sources that won't be an option. Lossless codecs are functionally equivalent to audio CDs. Lossy ones are not.
> Music in ALAC? I never saw it being sold anywhere.
Because almost nobody has any reason to want lossless music. Anyone buying music in FLAC is deluding themselves if they think they can hear a difference between that and a properly encoded lossy codec like MP3 or AAC.
> Any time you want to reencode your music, you care about the lossless codec for the source, otherwise you'll degrade your quality.
True. But this is an issue for so few people as to be effectively zero. Extremely few people actually do this sort of thing, and I would wager that most of them aren't Apple customers to begin with.
If Apple had infinite engineering resources, then yes, it would be nice to solve every single problem for every person, everywhere. But Apple's engineering resources are not infinite, and it would be a flagrant waste of those resources to spend them on issues like this that impact effectively zero Apple users.
Anyone buying music in FLAC is deluding themselves if they think they can hear a difference between that and a properly encoded lossy codec like MP3
Because of inadequacies of the MP3 encoding format, no bitrate of MP3, even the max, can encode all possible things that the human ear can distinguish. There is one song I know of with a particular synthesized effect in the upper treble that is very profoundly different from the lossless original even in a VBR0 or 320kbit MP3.
Additionally, I've read that MP3 (I don't know about AAC) doesn't preserve enough phase information for effective use with matrix-encoded (e.g. Dolby Pro Logic) surround sound audio.
But Apple's engineering resources are not infinite, and it would be a flagrant waste of those resources to spend them on issues like this that impact effectively zero Apple users.
What was wasteful was inventing ALAC instead of using FLAC.
> True. But this is an issue for so few people as to be effectively zero.
Why not? Keeping a master copy can be an issue for any user who cares about quality. You can see it as keeping a master tape, so any subsequent copy (=lossy encoding) won't degrade the quality too far.
> and I would wager that most of them aren't Apple customers to begin with.
Why so? Is it some kind of stereotype that Apple customers don't care about quality of music or can't be audiophiles?
> If Apple had infinite engineering resources, then yes, it would be nice to solve every single problem for every person, everywhere.
Adding FLAC support in their QuickTime framework is trivial. Excusing the lack of support for it by lack of engineering resources in Apple should be just embarrassing for them, not even to mention that it simply would be a lie.
> You can see it as keeping a master tape, so any subsequent copy (=lossy encoding) won't degrade the quality too far.
Yes, the concept is not what's at question here. What's at question is how many people actually are inclined to ever care about something like this, and the answer is almost nobody. Very few people care to reencode their audio files.
> Why so? Is it some kind of stereotype that Apple customers don't care about quality of music or can't be audiophiles?
Why do you leap to the worst possible assumption about everything Apple? You seem to have an extremely strong bias here.
Most Apple customers probably buy their music from the iTunes Music Store and don't ever think about reencoding it, because there's no point. Similarly, most people who buy music from other stores get it already encoded in a lossy format appropriate for listening to. Far and away the biggest reason to be reencoding is when ripping music from an audio CD, and iTunes already supports that. Once ripped, there's no reason to go about reencoding it again, as we've already long since passed the point where people can discern a difference.
The only really legitimate reason to be caring about this sort of thing is when you're doing professional audio work (as opposed to mucking about with music for personal listening), and people who are doing professional audio work aren't using iTunes for this work anyway so that's pretty irrelevant.
> Adding FLAC support in their QuickTime framework is trivial.
That's absurdly naive. It would be practically criminal negligence for Apple to download the latest libFLAC and drop it into the OS they ship to millions of customers without spending significant engineering resources reviewing the code. Then there's the ongoing maintenance burden, of dealing with upstream changes, local bugfixes, and just plain integration with the rest of the QuickTime stack. And if iTunes supports it, then iPhones and iPads really ought to support it if it's at all possible, and that's a really large engineering effort to do so in a way that's power-efficient, if that's even possible (given the lack of hardware support for it).
And that's just what comes to mind off the top of my head. I'm sure there's more that would be involved as well.
And for what? What would you gain from having iTunes support FLAC? You should be transcoding into some other format already for actual use in listening, because there's no point in carrying around large lossless files for personal listening, especially if you use any mobile devices (or laptops). You don't need iTunes to support FLAC just to transcode it, you already have options there, and as long as you aren't transcoding to Ogg Vorbis then your resulting file should work in iTunes (and on iPhones and iPads).
> Then there's the ongoing maintenance burden, of dealing with upstream changes, local bugfixes, and just plain integration with the rest of the QuickTime stack.
Yes, and Apple perfectly did all that when it came to their own ALAC, as you already mentioned. Not FLAC though. NIH I guess. Or just "screw your customer". Such serious company like Apple being unable to support FLAC with QA and upstream updates? I don't believe that. They just don't want to. And not because it's costly (it's nothing for them), and not because they are scared of legal threats (there are none - it's used in tons of places just fine). It's just Apple being Apple the way I see it.
>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".
> It has always been a strong goal of the JPEG committee that its standards should be implementable in their baseline form without payment of royalty and license fees...
It's only for baseline.
> is no different to Ogg or VP8 in that regard
They are patent free, no strings attached, unlike JPEG2000.
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.
ALAC was pure NIH, since FLAC existed before it. And it wasn't even open until much later. Anyway, it's not any excuse for Apple not to support FLAC. It's irrelevant to this subject really.
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?