This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There should be a way to stop ( and start ) media buffering once the while the media element is in the NETWORK_LOADING state. This has a few use cases such as: * Preventing a 3 hour video from downloading the entire video when the user only watches 5 seconds and leaves the tab open. This could save a lot of bandwidth. The user page could alternatively wait for a canPlayThrough event if the implementation supported it. It would be up to the site to notice that the user downloaded the first 30 seconds much faster than real time, and there would be no continues playback benefit to downloading the entire clip. * Creating video sequences with several sub clips with in and out points of much longer source media files. * Creating poor mans adaptive streaming by stopping buffing of stream A, loading another stream B, seeking to the stop buffer point in stream B, then remove A and show B once the time is reached in the stream A.
If I quickly pause a video and then switch away, there's a pretty good chance that I'm *purposely* letting it buffer freely, either because my connection is too slow to stream it live, or I expect to be without proper bandwidth later and am using the browser's video cache to store the video for later viewing. I definitely do not want sites stopping me from buffering so they can "save my bandwidth" (or, for that matter, theirs).
(In reply to comment #1) > I definitely do not want sites stopping me from buffering so they can "save my > bandwidth" (or, for that matter, theirs). Sites should be able to tune their service to deliver the best experience possible to as many people as possible. This means being able to pause buffering for users that download the clip much faster than playback rate. This also means being concise of connections that are not as fast and support buffering the entire clip, where there are risks of buffer under runs. Not sending video data that will never be used, enables severs to deliver the content to more visitors at lower cost.
My point is that your first example of "tuning the service to deliver the best experience possible" is actively bad for my use-case, producing a *much worse* experience. I'm used to videos buffering fully if I allow them to.
(In reply to comment #3) > My point is that your first example of "tuning the service to deliver the best > experience possible" is actively bad for my use-case, producing a *much worse* > experience. I'm used to videos buffering fully if I allow them to. You are free to view videos way you like (videohosting website may have settings where you can choose buffer usage strategy that is suitable for you personally). Do not confuse _ability_ to do something with using this always. What the bug is about is that buffering should be _controllable_ by web-application _when it's needed_ for a specific case. And this is quite reasonable. Lack of this feature is one of drawbacks of HTML5 video element compared with Flash-based players which are much more flexible.
this is something that hopefully DASH will help with in the future (as Smooth Streaming, HLS and the other fMPEG implementation do today) by taking advantage of small fragments, multiple bitrates and tuneable heuristics - allowing a site to (for instance) make a determination for their player to only download a certain number of fragments / %age of file / minutes of content if (for instance) the user switches away from the window the current <video> implementation could make the same decision and encode logic to suspend download of further content once the canplaythrough status has been reached (even though the content has not yet been delivered) and rely on the bandwidth remaining consistent enough that when the user switches focus back and hits play again then the remaining delivery portion will complete without causing buffering Something like http://www.w3.org/Bugs/Public/show_bug.cgi?id=14186 would add further support for this allowing the developer to make informed decisions based on returned http response codes and additional meta information
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Let's leave this to the browsers for now and see if we need to give the authors more control or if the browsers do a good enough job themselves.
> Status: Rejected > Change Description: no spec change > Rationale: Let's leave this to the browsers for now and see if we need to give > the authors more control or if the browsers do a good enough job themselves. I don't see how the browsers can "do a good enough job" themselves the point is that authors need a standard way to control buffering progress like they can with existing flash based web video distribution platforms. Its not a question of whether browsers can "do a good job" its a question of tuning this to application / site specific context that are unknown to the browser. Its comparable to saying web authors don't need JavaScript control to be able to lazy load non-visible image assets, because ~browsers should handle that~.