VP8 and H.264 to both become mandatory for WebRTC
andreasgal.com
andreasgal.com
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.
Does that trigger any of the reciprocal patent grant thingies that VP8 (and 9?) have and remove Nokia's patents from the picture?
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.
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.
AAC is nowhere patent free.
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.
Nobody's complaining Apple doesn't support actual MPEG ALS, for example.
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.
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.
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.
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).
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.
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.
Patents stop them (JPEG2000 is not a free format). FLAC is not patented. Q.E.D. Apple don't supported it just in order to be nasty to everyone.
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).
http://www.jpeg.org/jpeg2000/index.html
>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.
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.
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.
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.
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.
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.
For Apple, that's competitive advantage.
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.
What about the music market? Apple intentionally avoided supporting free codecs which are not patented. That's malice.
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.
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.
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.
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 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.
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.
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.
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.
Neither?! What? How will that work then?
"Why can't I see you on you on my webrtc compatible desktop app?!"
Like an end-user is going to recognize the difference in terminology.
The IETF itself of course recognizes that the current taxonomy may not be ideal from a marketing standpoint: http://ietfmemes.tumblr.com/image/102328432749
https://tools.ietf.org/html/draft-ietf-rtcweb-overview-12#se... mentions one concrete example of a WebRTC-compatible endpoint: a WebRTC Gateway that mediates between a WebRTC endpoint and a non-WebRTC endpoint.
Vague? Yes. Poor choice of words? Yes (both IMHO)
With this proposal, any WebRTC-compatible device can communicate with any browser with video.
Good job!
I think vp8 doesn't have too many hardware implementation either. h264's situation is better though.
The next generation codecs such as HEVC and VP9 are a lot more computationally expensive and do require a lot more die area.
So hopefully browsers implement more than the minimum.
Remember WebRTC also covers encoders.