10 ms·
H.264 is supported in WebRTC from Chrome 50
- leeoniya 11y agointeresting that there's an encoder built in as well. wonder if they will start offloading youtube video compression onto client machines pre-upload.
- ZeroGravitas 11y agoThe 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 11y agoFirefox and Chrome are also shipping VP9 for WebRTC.
- rdtsc 11y agoWell 2-way video conferencing is a major use case for WebRTC. It wouldn't make sense to skip the encoder.
- jallmann 11y ago> 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.
- amelius 11y ago> 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.
- jallmann 11y agoMassive increase in complexity (distributing and tracking encoding state), significant increase in resource usage for everyone (network transfer, CPU). Not a win.
- 0x006A 11y agorecent talk on VP10 (https://www.youtube.com/watch?v=LzKP7JJjXtY 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.
- cbhl 11y agoYou 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 https://news.ycombinator.com/item?id=4946275
- rasz_pl 11y agogoogle 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..
- VuWall-Matt 11y agoWould 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?
- ossreality 11y agoWebRTC in Chrome has already supported screen sharing for years.
- jallmann 11y agoYes, with the mediaSource constraint you can do screen sharing in WebRTC, but that's not anything specific to H.264.
- Excavator 11y agoFor 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 11y agoI'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 11y agoAFAIK 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 11y agoSupposedly 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.
- gillianseed 11y agoCisco 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/aom https://chromium-review.googlesource.com/#/q/project:webm/ao...
- cpeterso 11y agoCisco 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?
- imaginenore 11y agoWhat 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)
- deleted 11y ago[deleted]
- snuxoll 11y agoDepends 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 11y agoYou'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 11y agoIt'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.
- ZeroGravitas 11y agoSome 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.
- Scaevolus 11y agoIt can't be worse than VP9, which is what Hangouts has been using recently. It stutters a lot on most laptops.
- xgbi 11y ago
- jjcm 11y agoI'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 11y agoThat'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.
- homero 11y agoWake me up with h.265
- ksec 11y agoAnd HEVC licensing is still a bag of hurt.
- dk8996 11y agoHow big of a deal is this? Is there any new use-case that can be gained by this tech?
- TD-Linux 11y agoIt means that WebRTC can interoperate with legacy equipment without transcoding.