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