Why the HTML5 ‘Video’ Element Is Effectively Unusable
daringfireball.net
Why the HTML5 ‘Video’ Element Is Effectively Unusable
1–10 of 80 posts
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#2This is a problem that I find to be systemic in the HTML specs. Even in a world where every browser was somehow 100% compliant with the spec (never going to happen), we web developers would still be hitting our heads against the wall with browser inconsistencies because the spec chooses to make important behavior optional or subject to the browser-vendor's unique implementation.
Another example of this is HTML5 drag and drop, where things like what exactly starts a drag is left completely up to the browser, resulting in major differences in behavior between browsers, to the point of almost being unusable.
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#3Another flaw in the spec is that it provides no means to specify client buffering behavior: you cannot tell the client how many seconds to buffer before playback. This completely breaks the buffering model inherent in modern video compression systems and basically only works properly at all if the users' connection is far higher than the bitrate of the video.
Until HTML5 has basic feature parity with Flash's video capabilities, it will probably not be used very widely. This is of course ignoring the fact that Firefox doesn't support a video format that anyone actually uses, and the fact that IE (still unfortunately the most popular browser) doesn't support anything at all.
The sad reality is that a single system often has the advantage over a group of conflicting, incompatible systems; even if the single system is bad, one at least only has to compensate for its weaknesses, and not for everything else's.
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#4Another flaw in the spec is that it provides no means to specify client buffering behavior: you cannot tell the client how many seconds to buffer before playback. This completely breaks the buffering model inherent in modern video compression systems and basically only works properly at all if the users' connection is far higher than the bitrate of the video. Until HTML5 has basic feature parity with Flash's video ca…
[deleted]
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#5Its unusable because of auto-buffering? A simple onclick DOM replace will fix this (as the article mentions). I get that we want better tuning parameters, but really, the video tag is such an improvement over a flash player or embed tag that we're looking the gift horse in the mouth.
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#6That is a problem, but it seems like it would be very easy to move the image - click for video behavior into a pretty small JS library. Writing something like this probably wouldn't be all that terrible:
$(function() { $('#video_1').to_video('myvideo.mp4', 'myvideo.ogg'); });
I'd still rather do that than deal with Flash.
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#7Another flaw in the spec is that it provides no means to specify client buffering behavior: you cannot tell the client how many seconds to buffer before playback. This completely breaks the buffering model inherent in modern video compression systems and basically only works properly at all if the users' connection is far higher than the bitrate of the video. Until HTML5 has basic feature parity with Flash's video ca…
You can actually control the buffering/playback with JavaScript. There are various ways to do this; one is with the TimeRanges object http://www.whatwg.org/specs/web-apps/current-work/#normalize... which will give you a representation of available time regions in the video resource. You can use this to determine when you want the client to begin playback. Your code can receive this after registering for an event and seeking the video.
Another way is with the readyState of the media element. In particular you want to look for numeric value 4, HAVE_ENOUGH_DATA. From the WHATWG:
All the conditions described for the HAVE_FUTURE_DATA state are met, and, in addition, the user agent estimates that data is being fetched at a rate where the current playback position, if it were to advance at the rate given by the defaultPlaybackRate attribute, would not overtake the available data before playback reaches the end of the media resource.
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#8Another flaw in the spec is that it provides no means to specify client buffering behavior: you cannot tell the client how many seconds to buffer before playback. This completely breaks the buffering model inherent in modern video compression systems and basically only works properly at all if the users' connection is far higher than the bitrate of the video. Until HTML5 has basic feature parity with Flash's video ca…
You can actually control the buffering/playback with JavaScript. There are various ways to do this; one is with the TimeRanges object http://www.whatwg.org/specs/web-apps/current-work/#normalize... which will give you a representation of available time regions in the video resource. You can use this to determine when you want the client to begin playback. Your code can receive this after registering for an event and…
You can actually control the buffering/playback with JavaScript. There are various ways to do this; one is with the TimeRanges object http://www.whatwg.org/specs/web-apps/current-work/#normalize.... which will give you a representation of available time regions in the video resource.
I could understand this in mp4, which has a global index giving locations of all frames in the file, but how would this be possible in ogg, which has no global index? Without a global index, you can't know anything about time regions that you haven't yet downloaded.
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#9Earlier quoted context omitted.
You can actually control the buffering/playback with JavaScript. There are various ways to do this; one is with the TimeRanges object http://www.whatwg.org/specs/web-apps/current-work/#normalize... which will give you a representation of available time regions in the video resource. You can use this to determine when you want the client to begin playback. Your code can receive this after registering for an event and…
You can actually control the buffering/playback with JavaScript. There are various ways to do this; one is with the TimeRanges object http://www.whatwg.org/specs/web-apps/current-work/#normalize... . which will give you a representation of available time regions in the video resource. I could understand this in mp4, which has a global index giving locations of all frames in the file, but how would this be possible in…
Then it probably doesn't work with ogg :)
I personally think it's a huge mistake for Firefox to support only ogg. It's a bad time for fragmentation in the push for open video on the web.
It should still be possible to get a rough estimate for when to start playback. Good enough for buffered autoplay.
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#10The author demonstrated why Firefox, et al, made the correct choice on his example page. I visited his page using Firefox and the video would not play. My guess is that you need javascript turned on to play the videos on his site. I almost never enable javascript, and certainly would not do so just to watch a little video. It sounds like Firefox and others are trying to make the web pages more universally work.