Live data from Hacker News

Why the HTML5 ‘Video’ Element Is Effectively Unusable

daringfireball.net

51–60 of 80 posts

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#51
post #49

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?

What do you mean by "as much as possible"?

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#52
post #29

Earlier 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…

I don't see anywhere in the article or in the title where he says that you can't do X. One needs to, again, sweep the author's qualifier "effectively" under the rug in order to construct that straw-man.

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

#53

Earlier 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…

>The browser should have ABSOLUTELY NOTHING to do with video and audio decoding.

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

#54
post #47

Earlier 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.

IIRC the licensing terms on MPEG4 are pretty onerous.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#55

Earlier 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…

If firfox does do it I believe they would still technically be required to pay licensing fees. The only reason they wouldn't is because mpeg la does not pursue them.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#56
post #49

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?

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.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#57
post #54
post #47

Earlier quoted context omitted.

They could take their mountain of cash and pay the licensing fee like Chrome does.

IIRC the licensing terms on MPEG4 are pretty onerous.

It's capped at a few million dollars. A pittance for Mozilla.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#58
post #49

Earlier 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.

Why does the browser itself not implement its own buffering algorithm? I do not quite understand why this onus should be placed on the developer responsible for the video imbedding functionality of the hosted datum. Certainly allow the external developer the flexibility to override this functionality (easily enough done via language features of JavaScript). But why force all developers to implement competing but similar algorithms? (by example and anecdotal personal observations: netflix > hulu > CBS/tv.com, in terms of how buffering algos deal with potentially high but intermittent bandwidth [1]).

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

#59
post #47

Earlier 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.

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 features that Firefox has, so having a special feature-filled Mozilla-branded version and leaving everybody else out in the cold is not really an option.

Although Chrome supports H.264 video, I believe Chromium does not.

Re: Why the HTML5 ‘Video’ Element Is Effectively Unusable

#60
post #47

Earlier 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…

If Mozilla is more committed to open source ideology than making video actually work that's their choice, but they could do things differently if they wanted to.
Post reply on HN