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?
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:
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.
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'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.
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.
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.
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?
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.
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.
> 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.
Massive increase in complexity (distributing and tracking encoding state), significant increase in resource usage for everyone (network transfer, CPU). Not a win.
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..
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.
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?
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.
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.
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.
