4 ms·

There is no good reason to support H.264 What? Except for the fact that as a video site, all of my existing video is already in H.264. All of my encoding tool

There is no good reason to support H.264 What? Except for the fact that as a video site, all of my existing video is already in H.264. All of my encoding tools support H.264. Every other device I need to stream that video content too including mobile devices, tablets, Connected TV's, Blu-Ray players and Over the Top boxes (Roku, Boxee) support H.264 (generally at the hardware level).

cookiecaper 16y ago
The same argument applies to video sites. We shouldn't be held back and stuck on a proprietary format just because you don't want to write a script to go through and re-encode everything to WebM. H.264 heretofore has been "the standard", so of course most existing devices will have better support for H.264 video than for the not-even-one-year-old WebM. Google and Mozilla are attempting to change that to avoid a repeat of GIF or even MP3. The argument boils down to "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." And that's just a silly argument that could easily be applied to any number of things in technology, which is a very fast moving field. Things change a lot in this space and it's just one of those things you have to accept. Google has not obliterated or disabled your H.264 decoders. You are welcome to keep H.264 video around all you want (according, of course, to your license terms with the MPEG-LA). Removing native support from Chrom(e|ium) does not mean that all H.264 video is now magically broken or unplayable. If you are happy with H.264, you are free to continue to use it.
- mikeryan 16y ago
  "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.
- toddheasley 16y ago
  >The same argument applies to video sites. We shouldn't be held back and stuck on a proprietary format just because you don't want to write a script to go through and re-encode everything to WebM. Here's a question: If it's no biggie to re-encode everything as WebM, can't we wait to see if this threat of unreasonable H.264 licensing terms becomes reality and switch to WebM then?
  - ZeroGravitas 16y ago
    They are already unreasonable, hence the fact that they can't be mandated in a W3C standard, many governments have laws saying their communications shouldn't use such a codec, Mozilla can't ship it etc.
abdulla 16y ago
Let's rephrase this: "Except for the fact that as a web site, all of my existing HTML already works in IE6. All of my HTML tools support IE6. Every other device I need to view web content content too including Windows mobile devices, Windows tablets, and Microsoft Web TVs support IE6." These same arguments have been used before, imagine if they were successful at deterring open, royalty-free innovation --- where would we be now?

cookiecaper 16y ago

The same argument applies to video sites. We shouldn't be held back and stuck on a proprietary format just because you don't want to write a script to go through and re-encode everything to WebM. H.264 heretofore has been "the standard", so of course most existing devices will have better support for H.264 video than for the not-even-one-year-old WebM. Google and Mozilla are attempting to change that to avoid a repeat of GIF or even MP3. The argument boils down to "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." And that's just a silly argument that could easily be applied to any number of things in technology, which is a very fast moving field. Things change a lot in this space and it's just one of those things you have to accept. Google has not obliterated or disabled your H.264 decoders. You are welcome to keep H.264 video around all you want (according, of course, to your license terms with the MPEG-LA). Removing native support from Chrom(e|ium) does not mean that all H.264 video is now magically broken or unplayable. If you are happy with H.264, you are free to continue to use it.

mikeryan 16y ago
"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.
toddheasley 16y ago
>The same argument applies to video sites. We shouldn't be held back and stuck on a proprietary format just because you don't want to write a script to go through and re-encode everything to WebM. Here's a question: If it's no biggie to re-encode everything as WebM, can't we wait to see if this threat of unreasonable H.264 licensing terms becomes reality and switch to WebM then?
- ZeroGravitas 16y ago
  They are already unreasonable, hence the fact that they can't be mandated in a W3C standard, many governments have laws saying their communications shouldn't use such a codec, Mozilla can't ship it etc.

abdulla 16y ago

Let's rephrase this: "Except for the fact that as a web site, all of my existing HTML already works in IE6. All of my HTML tools support IE6. Every other device I need to view web content content too including Windows mobile devices, Windows tablets, and Microsoft Web TVs support IE6." These same arguments have been used before, imagine if they were successful at deterring open, royalty-free innovation --- where would we be now?