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 ca…
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?
Why the HTML5 ‘Video’ Element Is Effectively Unusable
51–60 of 80 posts
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#52Earlier quoted context omitted.
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 a result of his rather drawn out explanation, however, it appears as though he can achieve the result he desires, just not as simply as he would like and in a manner he'd rather make fun of than use. I understand complaining that about the lack of a feature that everyone seems to agree is decent and desirable, not to mention spelled out in the specification but it is not relevant to that specific discussion to com…
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.
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#53Earlier quoted context omitted.
How can Firefox distribute the H.264 codecs without infringing on patents?
How do Linux distributions distribute H.264 and AAC decoders? Debian does, Ubuntu does, Fedora does, basically everything in the world except GNUsense does--yet they do just fine with themselves. 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 NOTH…
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.
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#54Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#55Earlier quoted context omitted.
How can Firefox distribute the H.264 codecs without infringing on patents?
How do Linux distributions distribute H.264 and AAC decoders? Debian does, Ubuntu does, Fedora does, basically everything in the world except GNUsense does--yet they do just fine with themselves. 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 NOTH…
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#56Another 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 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?
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#57Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#58Earlier quoted context omitted.
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?
When you don't want the video to start, when you only want to buffer the minimum required for smooth playback, to avoid wasted bandwidth when the user inevitablly closes the window (see youtube, they do this now), a myriad of reasons. Flexability allows inovation.
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 52s 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.
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#59Earlier quoted context omitted.
How can Firefox distribute the H.264 codecs without infringing on patents?
They could take their mountain of cash and pay the licensing fee like Chrome does.
Although Chrome supports H.264 video, I believe Chromium does not.
Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable
#60Earlier quoted context omitted.
They could take their mountain of cash and pay the licensing fee like Chrome does.
Firefox could pay the licensing fee for the copies of Firefox they distribute themselves, but they can't pay the licensing fee for unknown downstream users - the various Linux distros who build their own Firefox builds, projects like Seamonkey and Camino, any random people who want to use the Gecko source for something. Mozilla is pretty committed to making sure that anyone who uses Gecko has access to all the HTML f…