Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

H.264 is supported in WebRTC from Chrome 50

rtc.news

Post reply on HN
Print view View original

21–30 of 49 posts

Re: H.264 is supported in WebRTC from Chrome 50

#21

Post by talonstriker »

imaginenore wrote: post #17
snuxoll wrote: post #14

Earlier quoted context omitted.

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.

Re: H.264 is supported in WebRTC from Chrome 50

#22

Post by amelius »

jallmann wrote: post #15
leeoniya wrote: post #2

interesting that there's an encoder built in as well. wonder if they will start offloading youtube video compression onto client machines pre-upload.

> 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 c…

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

Re: H.264 is supported in WebRTC from Chrome 50

#23

Post by 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.

Re: H.264 is supported in WebRTC from Chrome 50

#24

Post by 0x006A »

leeoniya wrote: post #2

interesting that there's an encoder built in as well. wonder if they will start offloading youtube video compression onto client machines pre-upload.

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.

Re: H.264 is supported in WebRTC from Chrome 50

#25

Post by jallmann »

amelius wrote: post #22
jallmann wrote: post #15

Earlier quoted context omitted.

> 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 c…

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

Re: H.264 is supported in WebRTC from Chrome 50

#26

Post by ZeroGravitas »

ppergame wrote: post #20
jordache wrote: post #6

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?

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.

Re: H.264 is supported in WebRTC from Chrome 50

#27

Post by cbhl »

leeoniya wrote: post #2

interesting that there's an encoder built in as well. wonder if they will start offloading youtube video compression onto client machines pre-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

Re: H.264 is supported in WebRTC from Chrome 50

#28

Post by TD-Linux »

jjcm wrote: post #23

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.

Re: H.264 is supported in WebRTC from Chrome 50

#29

Post by TD-Linux »

cpeterso wrote: post #10
jordache wrote: post #6

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?

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.

Re: H.264 is supported in WebRTC from Chrome 50

#30

Post by xgbi »

imaginenore wrote: post #12

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)

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?
Post reply on HN