It's a script to run ffmpeg over your video directories, scp/ftp/whatever it out to your CDN, and update a database somewhere (or use permalinks that don't care if the extension changes, or just keep the old extension on the filename even if it's not accurate anymore -- your users aren't seeing it anyway). It's definitely a scriptable undertaking if your application has any sanity.
I recognize that there is an associated transitory cost, like the extra disk space and bandwidth used, but, again, such costs are inherent in working in a quickly developing field of technology. HTML5 is new, still only a draft, and most browsers' support is adequate but not really "mature". Things are going to be changing with regard to HTML5 video, canvas, etc. now and in the future -- you may want to stick with Flash video or links to video files until HTML5 stabilizes further.
As stated, if you don't think it's worth your while to transcode to WebM, no one here is forcing you. You are totally free to keep everything H.264 and give Chrome users a Flash fallback.
Encoding video is not an automatic process that can be sent to a batch process and forgotten about; encoding is art, meaning it has to be done by someone who masters their tools, visually checks the result and adjust the process accordingly, for each video (even for each scene!)
Otherwise the result is shit.
So, changing codecs is a lot of work for content producers; maybe it's for the better, but don't say "it's just a script", because it simply isn't.
So, does YouTube have someone sit there and manually check every video to see if quality would be a little better if the bitrate was tweaked before (or after, for that matter) they publish it? What about Facebook or Vimeo? I think these prove that you can have an automated encode produce acceptable results.
If you care enough to be picky about the parameters used to encode a given video, then you're probably not uploading that video to YouTube in the first place, which gives the end-user no control whatsoever of the encoding parameters.
If you publish several hundred videos on your own and you've carefully tweaked and created an encoding profile for each one and you want to use the same care when transitioning to WebM, then I recognize that that will be pretty time-consuming for you. However, I sincerely doubt that's a very common case, and, as above, you don't have to switch to WebM if you don't want to. H.264 decoders still work.
"So, does YouTube have someone sit there and manually check every video to see if quality would be a little better if the bitrate was tweaked"
Of course they don't and no one expects them too. Have you seen the videos on youtube? The quality is wildly variable, with the mean-quality being shit.
For many other content — music vids, doccos, tv-shows, movies — quality is important.
"If you publish several hundred videos on your own and you've carefully tweaked and created an encoding profile for each one and you want to use the same care when transitioning to WebM, then I recognize that that will be pretty time-consuming for you. "
Which is precisely why so many people aren't interested in WebM.
"However, I sincerely doubt that's a very common case,"
You’re making assumptions. It may be very few people or it may be a lot. How confident are you when you say it's not very common? How did you come to this conclusion?
"However, I sincerely doubt that's a very common case, and, as above, you don't have to switch to WebM if you don't want to. H.264 decoders still work."
And thus, your entire argument in favor of WebM falls flat on its face. H.264 decoders not just "still work" but they are also the only way to get video to mobile devices at this time. So unless you want to ignore all mobile devices, you’ll at least not want to drop H.264 altogether, and maintaining two entire video catalogues at the same time is so very much not an attractive proposition when the alternative is maintaining only a single video catalogue—likely what everyone is doing right now as it is.
Why is H.264 the only way to get video to mobile devices? Can your mobile computers not make the computations necessary to decode video encoded in a codec not natively decoded by hardware? Software decoding is not impossible or even rare -- it's the common case except for a handful of codecs on a handful of devices.
So, why is it not possible for an iPhone or Nexus S to decode WebM?
I have an iPhone and other H.264 rendering devices, too. It sucks to know that WebM might be a problem. But I'm not so sure worrying about my phone purchase warrants this baffling cry of nonsense about Google dropping H.264.
Flash is installed everywhere, providing video, interactive content and millions of web experiences - but Steve says its gotta go. Fine, I concede that a proprietary sandtrap that encapsulates 90% of the interactive content on the web is probably a crappy thing.
So why the hate on Google for dropping royalty-laden H.264? Isn't this the same proprietary lip-stick-on-a-pig bullshit argument that Adobe was shooting around about Flash when Steve Jobs declared it the enemy of battery life?
It would be different if every single browser supported H.264 and Google was pulling the carpet out from under everyone. But that isn't the case.
I recognize that there is an associated transitory cost, like the extra disk space and bandwidth used, but, again, such costs are inherent in working in a quickly developing field of technology. HTML5 is new, still only a draft, and most browsers' support is adequate but not really "mature". Things are going to be changing with regard to HTML5 video, canvas, etc. now and in the future -- you may want to stick with Flash video or links to video files until HTML5 stabilizes further.
As stated, if you don't think it's worth your while to transcode to WebM, no one here is forcing you. You are totally free to keep everything H.264 and give Chrome users a Flash fallback.