H.264 is supported in WebRTC from Chrome 50 | Hacker News Reader

H.264 is supported in WebRTC from Chrome 50

rtc.news

128 pointsarnaudbud45 comments

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?

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

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

https://mozilla.github.io/webrtc-landing/gum_test.html

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?

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.

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

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.

Cisco is also a h264 patent holder, which may have given them a better licensing deal.

Beyond this, Cisco is part of the 'Alliance for Open Media', consisting of Google, Cisco, Intel, Netflix, Amazon, Microsoft, Mozilla (the latter funding Daala) who are building a new royalty free codec for their needs based upon vp10, but which will make use of any useful technology their members have access to.

Early days yet:

https://chromium-review.googlesource.com/#/q/project:webm/ao...

Cisco has a lot of hardware VoIP clients that use H.264 and they want to make sure that browsers can talk to them.

Google already ships an H.264 software decoder in Chrome, so I'm surprised they would (also) ship OpenH264. Maybe they don't want to pay extra for H.264 encoding licenses or to increase compatibility with other WebRTC clients using OpenH264?

Well, they need some H.264 encoder. Maybe they didn't want to buy the commercial license for x264. And OpenH264 is already battle tested in Firefox.

Note that OpenH264 is terrible and probably isn't viable for anything besides video conferencing and/or screen sharing.

A couple of things from their github issues: It's much slower than x.264[1]

It only supports baseline profile and the developers aren't that interested in going beyond that[2]

IIRC this quality was lower than x.264 even when set to baseline profile... I'll see if I can dig up some statistics.

[1]https://github.com/cisco/openh264/issues/2067 [2]https://github.com/cisco/openh264/issues/1844

That's a pointlessly inflammatory statement, particularly in the absence of any explanation of what you're referring to. Are you referring to code quality, the fact that it currently only supports the baseline profile, etc?

The tuning is and will always be far worse than x264, because no commercial team will ever have the motivation to beat the years of video encoding maniacs' free time spent on it.

Plus the Cisco employees probably aren't any good at Touhou games. Presumably they're pretty good at tuning video calls though.

Yeah, my comment now looks a bit weird after yaur silently edit the original post to add everything after the first sentence.

I still think “terrible” is a bad choice of wording – “slow” would be an objective statement of fact and the fact that it's within a factor of 2-3 of x264 is worth knowing but hardly enough to say nobody could use it.

x264 was and is a very good encoder for H.264, but it sounds a bit extreme to say that no one can ever beat it - real time streaming was never its primary use case. I think the real lack of motivation to improve it is because most of the interest is now in newer video formats, like VP9. Also, many of the developers of x264 were paid by the commercial licensing program, so I wouldn't say it didn't have any financial motivation.

Also, I'm proof that x264, in fact, does not have a monopoly on Touhou-playing video codec developers :)

The commercial licensing for x264 came about well after it was largely "finished" (there's still ongoing work being done, but no major improvements since 10-bit support in 2010). The idea of maybe selling it one day never really came up when all of the work that makes x264 interesting was being done.

You are right, it's not a good idea for anything other than video conferencing because of being Baseline only. I don't think that makes it "terrible" - WebRTC is only video conferencing.

That said, both Firefox and Chrome prefer VP8.

PR, I suspect. The license doesn't include support for H.264 Main Profile, so its utility is quite limited.

Their licence does include all profiles of H.264, their code as yet does not.

The blog announcing it can be found here: http://blogs.cisco.com/collaboration/open-source-h-264-remov...

Cisco sell a number of products that use H264 and so were already paying some fees (although not necessarily the max license level) for the use of this codec.

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

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

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.

Firefox and Chrome are also shipping VP9 for WebRTC.

Well 2-way video conferencing is a major use case for WebRTC. It wouldn't make sense to skip the encoder.

> offloading youtube video compression onto client machines

Interesting thought experiment, but there just isn't a compelling reason for doing so, and many drawbacks.

* The encoding might take a long time, users are fickle, and it and would unnecessarily drain power on laptops and mobiles. For smaller uploads where users might not notice, the transcoding farm isn't impacted as much.

* It wouldn't cover the range of codec/bitrate/resolution combinations that YouTube has to encode anyway.

* YouTube accepts a ton of input formats (thanks to FFmpeg), while this scheme would be only useful for a specific class of uploads where the browser has a decoder matching the upload (since you're technically transcoding).

* The matter of implementation: JS media handling APIs are fairly coarse (especially so WebRTC), even getting this to work in the browser would fall under the heading of "marvelous hack."

* OpenH264 supports a limited set of profiles (baseline only?), which doesn't compress nearly as well as other encoders, especially with multi-pass.

> Interesting thought experiment, but there just isn't a compelling reason for doing so, and many drawbacks.

How about:

* Partially encoding the video on the client, until the user decides to close the browser?

* Encoding the video on clients run by other youtube visitors in the background?

* The encoder could also be implemented in ASM.js, I suppose, so that would eliminate the problem of codec/bitrate/resolution.

Massive increase in complexity (distributing and tracking encoding state), significant increase in resource usage for everyone (network transfer, CPU). Not a win.

recent talk on VP10 (https://www.youtube.com/watch?v=LzKP7JJjXtY)

encoding videos is much more cpu intensive. offloading to client machines is not an option. its always better to get the source material and spend more cpu time on the server (with the option to do better later). There might be still some corner cases where you would want to encode raw or mostly uncompressed source material before upload.

You might be interested in the following article:

To stream everywhere, Netflix encodes each movie 120 times (gigaom.com) [2012] https://news.ycombinator.com/item?id=4946275

google keeps original file you upload

There are youtubers that uplaod 20GB extremely high bitrate files for their 1hour shows, and google lets them retrieve original files on demand.

It sounds crazy given amount of video material being uploaded to YT 24/7, no wonder Google wants new type of spinning hard drives, they must pay tens of millions per year for drives alone..

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

It means that WebRTC can interoperate with legacy equipment without transcoding.

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)

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.

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.

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.

Some of the speed comes at a cost of lower compression. Not that big a deal when it only has to got from camera to SD card, but important when it needs to get transmitted across the mobile internet in real-time.

It can't be worse than VP9, which is what Hangouts has been using recently. It stutters a lot on most laptops.

We (linphone) do H264 software encoding and reach 720 on high-end iPhones (5s and more). So 1080 should be doable in realtime with, say, 20 fps, on an i5 I'd say?

Are you using hardware accelerated encoding on iOS?

As I said, software encoding. Hardware encoding is coming but not yet there.

depends on how good you want the results to be. software encoders generally allow you to make tradeoffs in the bitrate-cpu-quality triangle.

And HEVC licensing is still a bag of hurt.

Wake me up with h.265

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.

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.

Reply on news.ycombinator.com