
VP8 and H.264 to both become mandatory for WebRTC - kinetik
http://andreasgal.com/2014/11/16/vp8-and-h-264-to-both-become-mandatory-for-webrtc/
======
shmerl
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?

~~~
eridius
> _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.

~~~
shmerl
_> 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.

~~~
anon1385
>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.

~~~
gcp
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.

~~~
eridius
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.

~~~
shmerl
_> 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.

~~~
eridius
> _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.

~~~
shmerl
_> 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.

~~~
eridius
> _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).

~~~
shmerl
_> 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.

------
rurounijones
> “WebRTC-compatible” endpoints will be allowed to do either codec, both, or
> neither.

Neither?! What? How will that work then?

~~~
cjbprime
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.

~~~
rurounijones
Seems like a marketing recipe for disaster.

"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.

~~~
derf_
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...](http://www.ietf.org/mail-
archive/web/rtcweb/current/msg13432.html)

The IETF itself of course recognizes that the current taxonomy may not be
ideal from a marketing standpoint:
[http://ietfmemes.tumblr.com/image/102328432749](http://ietfmemes.tumblr.com/image/102328432749)

------
yuhong
Hopefully this means MS is finally willing to support VP8 and hopefully WebM
too.

~~~
cwyers
Seeing as Microsoft is still pushing an alternative to WebRTC, I somehow doubt
it.

~~~
rictic
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](https://status.modern.ie/webrtcobjectrtcapi)

~~~
cwyers
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.

------
asmicom
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.

Good job!

------
MichaelGG
Does this matter? Implementors can and will just do whatever they want for
really critical things like this.

~~~
TD-Linux
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.

------
billconan
I thought this is vp9/h265 era already?

~~~
TD-Linux
Encoders for vp9 and h265 have a long way to go before they can compete for
real-time usage, such as WebRTC.

~~~
billconan
because they lack hardware implementation?

I think vp8 doesn't have too many hardware implementation either. h264's
situation is better though.

------
brunorsini
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.

~~~
TD-Linux
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.

~~~
fithisux
I thought OpenCL is a standard interface to create decoders. Moreover a DSP
could be exposed as an OpenCL machine.

------
higherpurpose
Only these two, or can others be used as well - such as Daala?

~~~
TD-Linux
Yes - both sides can offer any number of codecs, and will negotiate the best
one. MTI is only for a baseline for universal compatibility.

------
ck2
The problem is the minimum level for WebRTC is so low, it makes H.264 useless
for regular video decoding (like what you'd find on youtube).

So hopefully browsers implement more than the minimum.

~~~
gcp
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.

Remember WebRTC also covers _encoders_.

------
fithisux
Why not VP9?

~~~
gcp
WebRTC requires low-delay realtime encoding.

------
l33tbro
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.

------
markjonson
Seems like a marketing recipe for disaster.
[http://www.easycabs.com](http://www.easycabs.com)

