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?
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.
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.
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.
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.
Neither?! What? How will that work then?
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.
"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
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.
