Comment by mikeryan | Hacker News Reader

Comment by mikeryan | Hacker News Reader

Parent Full thread

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

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.

Why this is being downmodded is beyond me.

Edit: seriously, the parent's explanation is reasonable, well stated and relevant to the discussion.

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

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.

"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?

Because Apple almost completely controls the iOS platform, and they will not allow you to write a new codec for their browser.

If WebM takes off Apple will have to add support. Otherwise the ipad will be "that thing that doesn't play videos"

cookiecaper, you are my new fav HNer.

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.

"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?

Just because something is not automatable doesn't make it art. Sheesh.

Reply on news.ycombinator.com