4 ms·

"I don't want to put in the effort to switch to the new stuff, and my old stuff likes the old stuff better anyway, so Google is a jerk for trying to make the ol

"I don't want to put in the effort to switch to the new stuff, and my old stuff likes the old stuff better anyway, so Google is a jerk for trying to make the old stuff less common." - No the argument is that H.264 is still a much better supported format which works much better with an existing workflow, tools and media players (and a negligible licensing cost). Re-encoding to WebM does me no good if a large section of my target devices don't support it. If they support H.264 but not WebM I'm sticking to H.264, and happily paying the relatively negligible licensing fees. You also seem to be underestimating the complexity of re-encoding a video library. Its a massive and costly undertaking and hardly just taken care of with a shell script. You generally don't "re-encode" existing H.264 video to WebM. You re-encode baseline video at a higher bitrate down to WebM or H.264 at various bitrates. Frequently these source baseline videos are not stored as digital files - they are multi GB in size. We work with the UFC and re-encoding their content at one point required them re-sending digital tapes to the encoding house so they have high quality source video. Let alone the actual process. Even if you own your own encoding tools you generally need to re-encode, QA the resulting video, push it all out to your CDN and then change every link you've got point to the new video URL. If you're not encoding your own video but using an existing service you frequently have to pay for both bandwidth and encoding costs to redo your video you often pay per-minute of video. Its an extremely costly undertaking.

cookiecaper 16y ago
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.
- face 16y ago
  Why this is being downmodded is beyond me. Edit: seriously, the parent's explanation is reasonable, well stated and relevant to the discussion.
- bambax 16y ago
  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. (I agree with your last paragraph though).
  - cookiecaper 16y ago
    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.
    - KuraFire 16y ago
      "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.

cookiecaper 16y ago

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.

face 16y ago
Why this is being downmodded is beyond me. Edit: seriously, the parent's explanation is reasonable, well stated and relevant to the discussion.
bambax 16y ago
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. (I agree with your last paragraph though).
- cookiecaper 16y ago
  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.
  - KuraFire 16y ago
    "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.