Another 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.
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.
you cannot tell the client how many seconds to buffer before playback. This completely breaks the buffering model inherent in modern video compression systems
My understanding is that HTML5 browsers will attempt to buffer as much as possible; is there any reason you'd want less buffering?
Well, it won't be long till whatwg find another usability issue with `video` and stuff, and expanding HTML5 to a full featured bloated media player stack.
This 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.
Its 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.
That 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:
But see that's kinda stinky cos it's not semantic. You're not embedding the video element in the document so it can describe the content. It would be really cool if the js somehow could remove the video element or something and add it back in... but I dunno how possible that is.
Slightly related: the HTML5 'Audio' element is also effectively unusable.
I was building choreographi.es (http://choreographi.es) a while back and was using the JPlayer plugin for JQuery, which attempts to use HTML5 audio and then falls back on Flash for platforms which don't support it.
The gist of my app was that I needed to match movements _exactly_ to specific offsets in the music. Between Safari and Firefox, Firefox was dead on, while Safari randomly appeared to skew as it started playing from different points in the music, just enough to be significant. I'd imagine it was some bug in counting sampling rate. In the end I had to crack open the JPlayer code and force Flash all the time.
TL;DR Moral of the story? It's hard to expect implementation to be perfect for a not-yet-finished standard, but until then, someone (you/me/us?) needs to make the equivalent of a community quirksmode combined with automatic bug submission to the relevant engine so we can get on with our lives.
Unfortunately John is entirely wrong, about Firefox at least. Firefox does not buffer the entire media when autobuffer is not present. I don't know how he came to that conclusion, but just check out this page as an example:
Note that the progress bar on the controls does not turn to a lighter shade of gray until you press play - this means Firefox isn't buffering data unless you press play.
You may be correct for Firefox but on the latest Chrome beta, my progress bar looks blue both before and after I press the play button - there is no indication to me as to whether it is buffering or waiting for input.
How does the title call out the video element as "effectively unusable" when in the end Gruber actually crafts a page that works with the video element?
Sure, no client respects the autobuffer attribute, and there's no way to use a poster image without resorting to javascript, and you have to encode the video two different ways. But it still works. It works even if you stick to one format (you're just excluding clients) or don't play the javascript-dom-switchout game (the video autobuffers, you don't get a poster image at all).
Better title: HTML5 Video Element Has Glaring Issues, but Usable.
If you look up "effectively" in the dictionary, it means "in such a manner as to achieve a desired result". The author highlights the desired result of requiring the user to click on the poster before buffering is allowed to begin. He currently cannot achieve the result he desires. The title makes sense to me.
"As for why I refuse to embed Flash, let me put it this way. I use and highly recommend ClickToFlash, which blocks all Flash content by default. Why would I publish content using a technology that I personally block by default?"
Soon you will be blocking <audio> and <video> by default too, for the same reasons.
It's not the video and audio aspects of flash he is concerned about, it's the automatic loading and playing of content with flash that is annoying. Audio and video that doesn't load until you ask for it is perfectly acceptable.
The argument seems kind of silly. In 1993 when people started using images in their content, I'm sure people were making similar points. "My browser shouldn't download an image until I tell it to, it uses my bandwidth!" or "Don't download the image until I click it." And the web would be a different place if things were kept that way.
Now I'm not saying that the HTML5 video spec is perfect, but let me just provide a src and call it a day. Everything else should be out of my control.
You would change your mind in a hurry when your bandwidth bill comes in, or you run over your caps. That's basically what Gruber is saying: it's just not economically possible for people to embed video this way.
The 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.
Actually, your comment clearly illustrates why the choice Firefox et al. made is completely wrong. The only reason the video doesn't show in your browser is that he had been forced to use javascript hackery instead of a plain video elements to override this braindead default behavior. If they had made the correct choice, it would have worked for you, too.
I am sorry but that is insane. Today's web relies heavily on JavaScript. I recommend you get yourself a clean browser (maybe on a virtual machine), if you are paranoid about security (SecurityMatters huh?), and try using Google Maps, Google Calendar, et al.
They're not going through conniptions. A markup reader already can display images with the <img> tag, and video is to the web what images were in 1995. However, the spec has an easy fallback - anything inside the video tag will be displayed on the older browsers. SO, as you said, that's where a link to download the video could be.
However, that's not what content producers want. They don't want you to be able to directly store the video on your machine, that's why they obscure it behind ridiculously obfuscated Flash players, making you go through all of these conniptions. That way you can't (easily) get it on your portable player or your home theater computer.
[+] [-] DarkShikari|16 years ago|reply
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.
[+] [-] tumult|16 years ago|reply
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.
[+] [-] wmf|16 years ago|reply
My understanding is that HTML5 browsers will attempt to buffer as much as possible; is there any reason you'd want less buffering?
[+] [-] est|16 years ago|reply
[+] [-] unknown|16 years ago|reply
[deleted]
[+] [-] aw3c2|16 years ago|reply
[+] [-] tolmasky|16 years ago|reply
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.
[+] [-] ynniv|16 years ago|reply
[+] [-] pkulak|16 years ago|reply
<script type="text/javascript"> $(function() { $('#video_1').to_video('myvideo.mp4', 'myvideo.ogg'); }); </script>
<img class="really_a_video" id="video_1" src="mythumb.jpg" />
I'd still rather do that than deal with Flash.
[+] [-] bphogan|16 years ago|reply
[+] [-] newhouseb|16 years ago|reply
I was building choreographi.es (http://choreographi.es) a while back and was using the JPlayer plugin for JQuery, which attempts to use HTML5 audio and then falls back on Flash for platforms which don't support it.
The gist of my app was that I needed to match movements _exactly_ to specific offsets in the music. Between Safari and Firefox, Firefox was dead on, while Safari randomly appeared to skew as it started playing from different points in the music, just enough to be significant. I'd imagine it was some bug in counting sampling rate. In the end I had to crack open the JPlayer code and force Flash all the time.
TL;DR Moral of the story? It's hard to expect implementation to be perfect for a not-yet-finished standard, but until then, someone (you/me/us?) needs to make the equivalent of a community quirksmode combined with automatic bug submission to the relevant engine so we can get on with our lives.
[+] [-] cpearce|16 years ago|reply
http://pearce.org.nz/video/bunny-poster.html
Note that the progress bar on the controls does not turn to a lighter shade of gray until you press play - this means Firefox isn't buffering data unless you press play.
John's blog post is wrong.
[+] [-] latortuga|16 years ago|reply
[+] [-] theschwa|16 years ago|reply
[+] [-] generalk|16 years ago|reply
Sure, no client respects the autobuffer attribute, and there's no way to use a poster image without resorting to javascript, and you have to encode the video two different ways. But it still works. It works even if you stick to one format (you're just excluding clients) or don't play the javascript-dom-switchout game (the video autobuffers, you don't get a poster image at all).
Better title: HTML5 Video Element Has Glaring Issues, but Usable.
[+] [-] pohl|16 years ago|reply
[+] [-] briansmith|16 years ago|reply
Soon you will be blocking <audio> and <video> by default too, for the same reasons.
[+] [-] tdm911|16 years ago|reply
[+] [-] sgk284|16 years ago|reply
Now I'm not saying that the HTML5 video spec is perfect, but let me just provide a src and call it a day. Everything else should be out of my control.
[+] [-] po|16 years ago|reply
[+] [-] fhars|16 years ago|reply
[+] [-] SecurityMatters|16 years ago|reply
[+] [-] fhars|16 years ago|reply
[+] [-] IgorPartola|16 years ago|reply
[+] [-] kingkongreveng_|16 years ago|reply
Why are people going through conniptions trying to get a markup reader to be a video player?
[+] [-] bphogan|16 years ago|reply
However, that's not what content producers want. They don't want you to be able to directly store the video on your machine, that's why they obscure it behind ridiculously obfuscated Flash players, making you go through all of these conniptions. That way you can't (easily) get it on your portable player or your home theater computer.