Looks like Wikipedia is on track to become a big server of HTML5 WebM videos. The absence of H.264 support (assuming they hold on to that) might finally push Microsoft and Apple to support WebM out of the box. Maybe we will also see more hardware support for WebM in mobile devices...
Yes, and this is really exciting news.
Soon one day, publishing a video is as easy as publishing a img, the world will be then a more open and free place.
I liked this example: http://commons.wikimedia.org/wiki/File:Great_Feeling.ogv. It also showcases the subtitles feature of the player. It didn't play the first time I tried it (current stable Chrome on Ubuntu) but reloading helped.
I would be interested in knowing the financials behind this. Video is expensive to serve and store: these costs become more noticeable if they get a lot of growth of Video uploads.As much as I love HTML5 Video , it drives up your storage and transcoding costs by two to three times if decide to support WEBM, OGG and MP4(though I see they are not doing MP4). If they are transcoding the video ,then that would add to CPU costs. Of course, I am basing my assumptions of AWS, Zencoder etc. I would love to hear how to plan to contain costs.
Wikipedia currently holds a huge amount of storage and data, while it will be a lot of work for them to support videos, I assume they thought of the costs before hand.
Also, the true cost of videos isn't storing them in two formats, it's the various qualities, such as if I upload a 1080p and it gets converted to 480, 720, and 1080 for streaming.
I totally agree: the costs are number of formats supported times number of streaming resolutions supported. One video could potentially eat up 1 Gb of storage , if we add up all the formats- resolutions combination. (I am assuming that they will have multiple copies of the same video in different qualities. ) Plus transcoding and costs. A comparative text article might be stored and served at a fraction of the video costs.
I am sure Wikipedia has some of the brightest minds and they have thought about these numbers. I want to know what their analysis is for my own edification.
That makes sense, it would be nice to see what they're planning - how they plan - to support the new videos that will be sure to come. I wouldn't expect anything about it for awhile though, it's new, they're still learning, and they may change their approach early on.
So, nobody cares about more widely adopted <object/> which was supposed to be a solution for future media types and just happens to usually be more stable, have better perfomance and support much more media formats without having to invent new elements for each media type. Not even as a fallback.
(I'm a Firefox developer that happens to work on HTML5 audio and video).
I can reproduce your problem on Firefox 16.0.2 , and this is fixed, at least on our Nightly builds, perhaps before that. But it is certainly embarrassing and should not happen (and was not caught during our extensive testing and beta phases), I'll look into back porting the relevant patches.
