YouTube Explains Where HTML5 Video Fails
awjr writes "YouTube have pretty much come down on the side of Flash having major issues with the lack of features that the HTML5 <video> tag has and may never have."
← Back to Stories (view on slashdot.org)
Is the video tag in HTML5 a kludge? Yes. Is it more an ideal than a practical implementation? Sure. Can it compete with a commercial product that has been an accepted part of the web for over 10 years now? Perhaps not. Is it poorly implemented in most modern browsers, with no agreed upon video codec common to any two of them? Yep. Would it be getting any attention at all if Steve Jobs hadn't used it as part of his cheap excuse to block free flash apps from his iControlU line of products? Not likely.
But all that's missing the point. The point is that it's *OPEN* and not under the control of any nasty for-profit corporation. And that makes it superior. Who *cares* if it doesn't work worth a damn in actual practice?
SJW: Someone who has run out of real oppression, and has to fake it.
Without content protection, we would not be able to offer videos like this.
This rental is currently unavailable in your country.
Surprise, you aren't offering those videos.
Not trying to be confrontational but I don't understand your comment and hoped you could explain further.
I took your comment to mean that even though there were better formats available, MP3 became standard because it was open.
My confusion is thus-
1-when MP3 first started being widely used (I started using it extensively in 1997) it was competing with WAV files. There were no better formats.
2- MP3s are only 'open' in the sense that they don't have embedded DRM. It is still a proprietary format with license fees attached.
"YouTube have pretty much come down on the side of Flash having major issues with the lack of features that the HTML5 tag has and may never have."
I guess my point is that this sentence is terrible. How did you possibly allow this, /. mod?
HTTP lets you seek to a byte range, but how does that map to a location within the file?
Find the known timestamps before and after the desired seek point, interpolate where you would need to seek if the part between known timestamps had a constant bit rate, and seek to that part of the file. The last article about Ogg vs. MKV presented a test result that it takes on average 3.5 iterations of this algorithm to get to the right part.
This could be worked around by putting this data in the header somewhere.
AVI has such an index. Matroska (wrapper used by WebM) has an index. Ogg does not, but unless you're on a satellite link, four HTTP seeks won't kill you.