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.