undefined | Better HN

0 pointscallahad11y ago0 comments

Is it really that difficult to supply a free format like WebM in addition to patent-encumbered H.264? If you only supply H.264, you're cutting out Firefox on OS X, Chromium, and Opera.

0 comments

xooyoozoo11y ago

Interestingly, the gif->mp4 in the source link uses Constrained Baseline H264, the only profile that's supported by Cisco's BSD-licensed OpenH264[1]. The MPEG-LA patent fees are already covered, so that small projects can freely use the decoder/encoder.

[1] https://github.com/cisco/openh264

garblegarble11y ago

It does mean you need to transcode and store twice as many files, which can be a serious pain if you've got a number of different bitrate H.264 assets. It can be a big pain if your software assumes there'll only be a single media file. Not insurmountable but painful for small operations (and for large operations, where there may be a back-catalogue to worry about)

I'm with you in spirit, but in practice I think we can all understand why people often just go for H.264

kibibu11y ago

This is a new feature launched by one of the biggest web brands there is, so presumably theres no back catalogue.

cookiecaper11y ago

Yes, until we get client-side transcoding, it is that difficult. Video files, even files compressed with modern codecs, are really big, and the concepts are generally really hard for most people to grok. The knowledge is so arcane that if you have a basic grasp of ffmpeg you are already a wizard. Most people's eyes will glaze over the second you start talking about how they should use a different container, or codec, or whatever. That's why GIFs (for sub-one-minute videos) and Flash (for long videos and/or videos with sound) became the universal language of video; there was no more "Here's this video, but you have to install WMP/RealPlayer/QuickTime/Bonzai Buddy to see it!" In fact, Flash probably became the standard because it did such a good job at integrating with the rest of the browser and didn't shove obtrusive branding in the user's face.

The tl;dr is that the support needs to very near universal for this to work, and no one is interested in WebM. Google probably could've forced the issue with YouTube, and they initially claimed they were going to, but they chickened out for some reason. I've heard it's because VP8 didn't live up to expectations and that they'll renew the push when VP9 is done, but whatever the motive, the reality is that if you want HTML 5 video to work, you must use H.264, as even Mozilla has been forced to admit.

callahadOP11y ago

> Video files, even files compressed with modern codecs, are really big, and the concepts are generally really hard for most people to grok.

As the article points out, the video files are generally much smaller than the source gifs.

Similarly, while there are real impediments to transcoding for many developers, I'm confident that the Twitter engineers in this specific case are capable of building a VP8 pipeline. After all, they built one for H.264.

At that point, achieving universal support is as simple as having two <source> tags inside your <video> tag. It's not difficult at all: http://www.html5rocks.com/en/tutorials/video/basics/#toc-spe...

cookiecaper11y ago

Yes, in this specific case, application-specific compression codecs are better for the storage of video, but that doesn't mean that video is small and that you can afford to transcode 4-8 different copies for every single image that would be uploaded (avail resolutions * formats * single piece of content), as that requires both a lot of CPU and a lot of disk space. It also doesn't mean any person around you has the expertise to figure out how to do this in a semi-reasonable manner, because as stated, most people don't understand the concepts used in modern video storage. You also assume that either WebM or H.264 will be supported by the user's browser. I don't think this is entirely correct, and in any case, it may always change, at which point the demand on the individual site becomes that much worse.

I think the real solution is to automate this and allow the client to request on-the-fly transcodes to the formats the browser can support, similar to the way some UPnP servers work.

j / k navigate · click thread line to collapse

0 comments

xooyoozoo11y ago

[1] https://github.com/cisco/openh264

garblegarble11y ago

I'm with you in spirit, but in practice I think we can all understand why people often just go for H.264

kibibu11y ago

This is a new feature launched by one of the biggest web brands there is, so presumably theres no back catalogue.

cookiecaper11y ago

callahadOP11y ago

> Video files, even files compressed with modern codecs, are really big, and the concepts are generally really hard for most people to grok.

As the article points out, the video files are generally much smaller than the source gifs.

At that point, achieving universal support is as simple as having two <source> tags inside your <video> tag. It's not difficult at all: http://www.html5rocks.com/en/tutorials/video/basics/#toc-spe...

cookiecaper11y ago

I think the real solution is to automate this and allow the client to request on-the-fly transcodes to the formats the browser can support, similar to the way some UPnP servers work.

j / k navigate · click thread line to collapse