
H.264 is supported in WebRTC from Chrome 50 - arnaudbud
http://www.rtc.news/posts/pawtYYfpmsG6Zed3W/h-264-is-supported-in-webrtc-from-chrome-50-here-s-how-to
======
VuWall-Matt
Would this mean that you can encode the Chrome windows itself and send it off
over the network to be decoded by, well, anything that decodes H.264, possibly
another Chrome window's decoder?

~~~
jallmann
Yes, with the mediaSource constraint you can do screen sharing in WebRTC, but
that's not anything specific to H.264.

~~~
Excavator
For a demo of screen, window, and application sharing see:

[https://mozilla.github.io/webrtc-
landing/gum_test.html](https://mozilla.github.io/webrtc-landing/gum_test.html)

------
jordache
I'm surprised I have not come across OpenH264. Why is Cisco eager to pony up
the license fees for users of their H264 codec?

~~~
atopal
AFAIK they don't. There is a cap on licensing for H264. Cisco is already
hitting that limit with their commercial offerings, so they can essentially
offer OpenH264 at zero (licensing) cost.

~~~
clouddrover
Supposedly offering OpenH264 ended up costing Cisco more money in licensing
fees. See Monty Montgomery's blog post from 2013 about the initial
announcement of OpenH264:

[http://xiphmont.livejournal.com/61927.html](http://xiphmont.livejournal.com/61927.html)

There are a couple of comments in the comments section titled "Cisco's Costs"
in which Monty says that someone he knew at Cisco told him that they had been
under the licensing cap and that the OpenH264 project would increase their
licensing costs.

------
leeoniya
interesting that there's an encoder built in as well.

wonder if they will start offloading youtube video compression onto client
machines pre-upload.

~~~
ZeroGravitas
The browser makers all agreed to support both VP8 and H.264 encode and decode
as part of a big compromise in the IETF standards body. It means non-browser
clients can implement one or the other (depending on if they're hippies or
corporate) and still be able to talk to any browser (except Safari, which I
think is still quiet on what it's WebRTC approach will be.

~~~
cpeterso
Firefox and Chrome are also shipping VP9 for WebRTC.

------
dk8996
How big of a deal is this? Is there any new use-case that can be gained by
this tech?

~~~
TD-Linux
It means that WebRTC can interoperate with legacy equipment without
transcoding.

------
imaginenore
What kind of computer would one need to encode H.264 1080p in real time?

(I assume it's all done on the CPU, not the GPU)

~~~
snuxoll
Depends on bitrate. I mean, my old Lumia 920 with a underpowered dual-core ARM
CPU could encode 1080p at 10Mbits/sec from the camera module - really
shouldn't be an issue for any modern PC to have video-conference quality
video.

~~~
imaginenore
You're confusing hardware encoding with software encoding. Your phone doesn't
do it on its CPU (or GPU for that matter). The camera module usually has a
separate chip for the encoding.

~~~
talonstriker
It's not part of the Camera module, but you're right that there is a dedicated
h/w core for it.

Some lower end SoCs just do it in the DSP.

------
ksec
And HEVC licensing is still a bag of hurt.

------
homero
Wake me up with h.265

------
jjcm
I'm excited for this simply because it means you can have a fully client side
in browser youtube downloader. With things like youtube-dl, you need ffmpeg to
combine the higher bitrate streams if you're downloading anything 1080p and
above. Most downloaders offload to a server to handle this, but it always
bugged me when I had to do that.

~~~
TD-Linux
That's not actually what it means at all. youtube-dl doesn't reencode, it just
remuxes the audio and video streams back together. You could do this in JS
already.

