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