Why the HTML5 ‘Video’ Element Is Effectively Unusable
daringfireball.net
daringfireball.net
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.
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.
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.
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.
The best solution would be to simply use system decoders, like Safari does. On Windows, this would be Directshow, on Linux this would be Gstreamer, and on OS X this would be Quicktime. The browser should have ABSOLUTELY NOTHING to do with video and audio decoding.
They do not. For Debian and Ubuntu, it is in Multiverse (non-free) repositories. For Fedora, it in RPM Fusion repository. In other words, there is no distribution that distributes H.264 or AAC, so system decoders would not help at all.
I know! While we're at it, who had the brilliant idea to put image decoders in browsers? I say let QuickTime decode GIFs and PNGs.
Although Chrome supports H.264 video, I believe Chromium does not.
Mozilla already has compile flags that generate binaries other people aren't allowed to distribute -- the logo and trademarks are decidedly non-free, hence IceWeasel.
There's a lot wrong with Theora, but it's irrelevant to the discussion: what matters is what people actually use. If today it came up that there was a big patent on JPEG, would you propose that the entire web stop using JPEG tomorrow?
No matter how good or bad Theora is, the internet will not simply drop the existing standard formats and switch. It doesn't work that way.
This is also why browsers should use system decoders: it would make it easier to use a different video or audio format, since one could use anything that people had decoders installed for. This would stop the internet from being locked into a single format.
"Use the system's video" sounds attractive, but just pushes the problem down the stack. Your mileage may differ, but I've seen people try it before....
My understanding is that HTML5 browsers will attempt to buffer as much as possible; is there any reason you'd want less buffering?
If this were abstracted to the browser level (discounting the fact that these long-format providers will likely never move away from their current flash/silverlight implementations), my choice of online tv watching would no longer be dependant on the competence of the content-providers buffering algorithm: currently, despite the fact that I enjoy several shows provided by CBS.com, I will not watch them online due to their shoddy buffering algos. I will not watch them via antenna, either (I watch on my own schedule, thanks).
Of course, as stated, these providers are hopelessly locked to their delivery platform due to DRM and contractual obligations. Ergo, most of this point is moot when it comes to long-format TV-oriented content distribution.
[1] in my experience, CBS does not buffer enough before playing, and does not buffer during the pause state. It also does not indicate how 'full' the buffer is during pause state, like hulu does. Netflix is, in my opinion, the best on this as it indicates on the seekbar the buffer level, and adjusts bitrate based on perceived bandwidth. When your bandwidth drops below the perceived bandwidth, it gives you an accurate status indication as to buffering activity. CBS, contrarily, simply buffers to the original perceived value and resumes play. This is problematic if you begin with high bandwidth but midway through stream something happens to negatively effect your bandwidth. If this situation occurs, you're likely to encounter a slideshow: video resumes for 5< seconds, whereupon it buffers once more. This results in >2s stutters every 3-10 seconds. Because CBS does not buffer during pause states, this renders the video unwatchable except during time periods when my bandwidth is constant: living on a highly variable cable node makes this time period nigh impossible to predict. Therefore I do not watch CBS shows - antenna or streaming - at all.
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.
<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.
Why not just add an onclick that puts in the `<source>` tags?
that way you still have a `<video>` tag but it has nothing to preload until you click it
note: I havn't tested this approach
Edit: Ok so I tried that in firefox and it doesn't work. But What if you make a video with 1 frame and a resolution of 1x1 and make that the source. Then you can replace that with onclick? (this one is more work than I'm willing to do out of curiosity, maybe someone else will try it?)
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.
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.
Result? The video jumps back to the beginning of the play cycle. Thus, I deduce, it ain't loading. Firefox 3.5 here, no autobuffer. Safari does as Gruber says and starts loading immediately.
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.
The title says that you can't effectively do X using Y. I don't see how the fact that one can do X by instead using A and B in combination with Y invalidates that statement, especially with all the hype built up around Y as the savior of all from the evils of F.
It doesn't feel right to drop carefully-chosen words in order to wage a critique.
My interpretation agrees with the Webster's dictionary's (http://www.merriam-webster.com/dictionary/EFFECTIVELY) first definition of "effectively": "in effect : virtually <by withholding further funds they effectively killed the project>". (There are other ways of killing the project more effectively)
I agree with you in the sense that the author goes on rambling about how he is unable to achieve X as effectively ("in an effective manner <dealt with the problem effectively>") as he would like, but this is not the claim he has made in the title.
x is effectively unusable
x is unusable effectively
As far as markup is concerned, he used an img tag, not a video tag, so he couldn't use the video tag in the markup, at which point either meaning is perfectly valid.
I can see how it might appear that way, but take note of the word "virtually" in the Webster's definition. It's an unfortunate word, because it undermines the absolute strength of the word it modifies...which, in your case, would be the word "impossible" (had you not dropped the word "virtually" from your paraphrasing, that is).
Here's another example that shows someone else using the word in the same way that this author does. His system is copying files very slowly, and while technically his system is able to copy files, he feels it can't effectively be used for that purpose, even though a more patient person might disagree:
http://www.vistax64.com/vista-performance-maintenance/120356...
Soon you will be blocking <audio> and <video> by default too, for the same reasons.
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.
It has the nice benefit that a lot of distracting annoyances (just to mention snap.com, most advertising, those pesky "2000 social web icons popup" footers) simply disappear.
If you want '"today's web"' with all its glittery blingbling and distractions, then go ahead. But don't fall for the illusion that you would miss anything by browsing with Javascript off by default.
The only exceptions are Google Maps or anything equally as rich. And I do mean equally as rich.
Like I said, Google Maps is my yardstick - anything less complicated than that should be built to work without Javascript. It might work slightly different and be a little less pretty, but there's no reason it can't work.
I read an interesting analogy in an article (which I have since lost and so cannot give credit) about accessibility: Oxo, the kitchen tools company, started by designing tools for people with arthritis. Having designed tools with nice soft rubber grips and large handles, they discovered that non-arthritic people really liked the tools as well, and now Oxo is sold at your local Target (and they are probably raking in cash).
Javascript is a great way to enhance the user experience, but you are being irresponsible if you develop sites that only work with JS enabled. It's seriously not that hard. Make it work first, then detect xhr on the server to add the nice partial updates, etc. And don't tell me it costs more money to do that. If it does, you designed it wrong or chose tools that are inherently inaccessible. In both cases the blame falls on you.
Full disclosure; I am a low-vision web application developer, born with congenital cataracts, along with my father and my daughter. Developers who use the excuse of "you have to have JS on for my stuff to work" make me incredibly angry, so I tried to keep this as civil as possible.
I've never used Google Calendar. I went over the code in Google Maps before I decided it was reasonably safe. That takes some time, and I have to do it every once in a while, since Google changes it. Most sites are not worth that trouble.
I don't say you are insane for blithely running javascript. You just obviously don't care much about security. That is your decision.
Why are people going through conniptions trying to get a markup reader to be a video player?
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.