4 ms·

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 playbac

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.

deleted 17y ago
[deleted]
tumult 17y ago
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/#normalized-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.
- DarkShikari 17y ago
  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.. 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.
  - tumult 17y ago
    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.
    - pyre 17y ago
      The problem being patents/licensing. mp4 is patented up the 'wazoo' and has onerous licensing terms.
    - windsurfer 17y ago
      How can Firefox distribute the H.264 codecs without infringing on patents?
      - DarkShikari 17y ago
        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 NOTHING to do with video and audio decoding.
est 17y ago
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.
aw3c2 17y ago
Your constant Theora bashing is so wrong. H264 is patented, patents are bad, Theora seems the best alternative. Get over it.
- DarkShikari 17y ago
  When did I bash Theora? 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.
  - aw3c2 17y ago
    I get the impression that you constantly do, but I might be wrong. System decoders (while being a sensible idea) actually reminds me of the web before Flash when people simply embedded wmv, mov etc. Why did one stop doing that again? Because of too many incompatibilities. And that's where you would end again. A standard format is the best solution, it is a shame the W3C was not that bold.
  - ZeroGravitas 17y ago
    It's a bit disingenuous to claim to promote choice when you're fully aware that the "choice" would be h.264 and that network effects would then render this a de-facto standard.
  - jdowdell 17y ago
    System-level video decoders were used in Macromedia Director during multimedia and early Internet days, but developers found it didn't work very well... you had to choose an architecture(s), then had to test for its presence and do version-detection, then handle the installation/support process for audience members who needed it. "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....
wmf 17y ago
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?
- DenisM 17y ago
  So that playback starts quicker?
- kierank 17y ago
  What do you mean by "as much as possible"?
- TeHCrAzY 17y ago
  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.
  - warfangle 17y ago
    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 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.

deleted 17y ago

[deleted]

tumult 17y ago

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/#normalized-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.

DarkShikari 17y ago
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.. 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.
- tumult 17y ago
  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.
  - pyre 17y ago
    The problem being patents/licensing. mp4 is patented up the 'wazoo' and has onerous licensing terms.
  - windsurfer 17y ago
    How can Firefox distribute the H.264 codecs without infringing on patents?
    - DarkShikari 17y ago
      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 NOTHING to do with video and audio decoding.

est 17y ago

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.

aw3c2 17y ago

Your constant Theora bashing is so wrong. H264 is patented, patents are bad, Theora seems the best alternative. Get over it.

DarkShikari 17y ago
When did I bash Theora? 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.
- aw3c2 17y ago
  I get the impression that you constantly do, but I might be wrong. System decoders (while being a sensible idea) actually reminds me of the web before Flash when people simply embedded wmv, mov etc. Why did one stop doing that again? Because of too many incompatibilities. And that's where you would end again. A standard format is the best solution, it is a shame the W3C was not that bold.
- ZeroGravitas 17y ago
  It's a bit disingenuous to claim to promote choice when you're fully aware that the "choice" would be h.264 and that network effects would then render this a de-facto standard.
- jdowdell 17y ago
  System-level video decoders were used in Macromedia Director during multimedia and early Internet days, but developers found it didn't work very well... you had to choose an architecture(s), then had to test for its presence and do version-detection, then handle the installation/support process for audience members who needed it. "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....

wmf 17y ago

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?

DenisM 17y ago
So that playback starts quicker?
kierank 17y ago
What do you mean by "as much as possible"?
TeHCrAzY 17y ago
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.
- warfangle 17y ago
  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 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.