- From: Zachary Ozer <zach@longtailvideo.com>
- Date: Mon, 17 Jan 2011 19:05:10 +0000
What no one has mentioned so far is that the real issue isn't the network utilization or the memory capacity of the devices, it's bandwidth cost. The big issue for publishers is that they're incurring higher costs when using the <video> tag, which is a disincentive for adoption. Since there are situations where both the publisher and the user are potentially incurring bandwidth costs (or have other limitations), we could allow the publisher to specify downloadBufferTarget and the user to specify a setting in the browser's config. The browser would then actually buffer min(user setting, downloadBufferTarget). At that point there would probably need to be another read-only property that specified what value the browser is currently using as it's buffer length, but maybe the getter for downloadBufferTarget is sufficient. Best, Zach -- Zachary Ozer Developer, LongTail Video w: longtailvideo.com ? e: zach at longtailvideo.com ? p: 212.244.0140 ? f: 212.656.1335 JW Player? |? Bits on the Run? |? AdSolution On Mon, Jan 17, 2011 at 6:19 PM, Roger H?gensen <rescator at emsai.net> wrote: > On 2011-01-17 18:36, Markus Ernst wrote: >> >> Am 17.01.2011 17:41 schrieb Jeroen Wijering: >>> >>> We are getting some questions from JW Player users that HTML5 video is >>> quite wasteful on bandwidth for longer videos (think 10min+). This because >>> browsers download the entire movie once playback starts, regardless of >>> whether a user pauses the player. If throttling is used, it seems very >>> conservative, which means a lot of unwatched video is in the buffer when a >>> user unloads a video. >> >> Could this be done at the user side, e.g. with some browser setting? Or >> even by a "stop downloading" control in the player? An intuitive user >> control would be separate stop and pause buttons, as we know them from tape >> and CD players. Pause would then behave as it does now, while stop would >> cancel downloading. > > I think that's the right way to do it, this should be in the hands of the > user and exposed as a preference in the browsers. > Although exposing (read only?) the user's preferred buffer setting to the > HTML App/Plugin etc. would be a benefit I guess as the desired buffering > could be communicated back to the streaming server for example for a better > bandwidth utilization. > > > > -- > Roger "Rescator" H?gensen. > Freelancer - http://www.EmSai.net/ > >
Received on Monday, 17 January 2011 11:05:10 UTC