Re: [whatwg] Limiting the amount of downloaded but not watched video
On Thu, 20 Jan 2011 01:14:12 +0100, Glenn Maynard gl...@zewt.org wrote: On Wed, Jan 19, 2011 at 8:22 AM, Philip Jägenstedt phil...@opera.comwrote: If the available bandwidth exceeds the bandwidth of the resource, some kind of throttling must eventually be used. There are mainly 2 options for doing this: 1. Throttle at the TCP level by not reading data from the socket (not at all to suspend, or at a controlled rate to buffer ahead) 2. Use HTTP byte ranges, making many smaller requests with any kind of throttling at the TCP level You're talking about Opera's implementation and not in spec, right? Yes, I'm just sharing my reasoning and conclusions. This is something UA's should have a lot of freedom with, and I assume this low-level detail about how to use HTTP is out of scope for the HTML spec. While I hope other implementors will take a similar approach (wildly different behavior between browsers would like result in worse interoperability), the spec shouldn't talk about HTTP or TCP, at least not normatively. (Since there is some overhead with each HTTP request, one must make sure that they are not unreasonably small.) When HTTP byte ranges are used to achieve bandwidth management, it's hard to talk about a single downloadBufferTarget that is the number of seconds buffered ahead. Rather, there might be an upper and lower limit within which the browser tries to stay, so that each request can be of a reasonable size. Neither an author-provided minumum or maximum value can be followed particularly closely, but could possibly be taken as a hint of some sort. Does it actually make sense to specify the read-ahead size, or should it simply be a flag (eg. unlimited, small buffer and don't care)? Is there really a case for setting the actual read-ahead value directly? In a sense, that seems akin to allowing web pages to control the TCP buffer sizes used by the client's browser--it's lower level than people usually care about. In particular, I'm thinking that most of the time all people care about is read ahead a little vs. read ahead a lot, and publishers shouldn't need to figure out the right buffer size to use for the former (and very likely getting it wrong). I'm inclined to agree, and we already have a way to say a little (preload=none/metadata) and a lot (preload=auto). However, it'd be great if all implementors could agree on the same interpretation of states. Specifically, this isn't required by the spec but would still be helpful to have consistency in: * effective state can only increase to higher states, never go from e.g. metadata to none (it makes no sense) * there is a state - invoked - between metadata and auto for when the video is playing * there could be a state between invoked and auto for autoplay, but if not autoplay implies preload=auto * in the invoked state, a conservative buffering strategy is used by default * when paused in the invoked state, we need to agree on what should happen If we could agree, then of course it should be documented somewhere, even if it seems somewhat restrictive of the spec to mandate an exact behavior. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Limiting the amount of downloaded but not watched video
On Jan 20, 2011, at 9:14 AM, Philip Jägenstedt wrote: (Since there is some overhead with each HTTP request, one must make sure that they are not unreasonably small.) When HTTP byte ranges are used to achieve bandwidth management, it's hard to talk about a single downloadBufferTarget that is the number of seconds buffered ahead. Rather, there might be an upper and lower limit within which the browser tries to stay, so that each request can be of a reasonable size. Neither an author-provided minumum or maximum value can be followed particularly closely, but could possibly be taken as a hint of some sort. Does it actually make sense to specify the read-ahead size, or should it simply be a flag (eg. unlimited, small buffer and don't care)? Is there really a case for setting the actual read-ahead value directly? In a sense, that seems akin to allowing web pages to control the TCP buffer sizes used by the client's browser--it's lower level than people usually care about. In particular, I'm thinking that most of the time all people care about is read ahead a little vs. read ahead a lot, and publishers shouldn't need to figure out the right buffer size to use for the former (and very likely getting it wrong). I'm inclined to agree, and we already have a way to say a little (preload=none/metadata) and a lot (preload=auto). However, it'd be great if all implementors could agree on the same interpretation of states. Specifically, this isn't required by the spec but would still be helpful to have consistency in: * effective state can only increase to higher states, never go from e.g. metadata to none (it makes no sense) * there is a state - invoked - between metadata and auto for when the video is playing * there could be a state between invoked and auto for autoplay, but if not autoplay implies preload=auto * in the invoked state, a conservative buffering strategy is used by default * when paused in the invoked state, we need to agree on what should happen If we could agree, then of course it should be documented somewhere, even if it seems somewhat restrictive of the spec to mandate an exact behavior. Perhaps the conservative buffering strategy should be client-side throttling after all. The pause-to-buffer argument several people put forward is a strong one - a big use case (perhaps more people pause b/c of this than b/c of all other reasons combined). Something like a downloadBufferTarget would be confusing and break this. Client-side throttling won't. - Jeroen
Re: [whatwg] Value of media.currentTime immediately after setting
On Thu, 20 Jan 2011 04:20:09 +0100, Matthew Gregan kine...@flim.org wrote: Hi, The media seek algorithm (4.8.10.9) states that the current playback position should be set to the new playback position during the asynchronous part of the algorithm, just before the seeking event is fired. This implies the following behaviour: 0. Initial load state (currentTime reports 0) 1. currentTime set to 20 by script 2. currentTime continues to report 0 3. Script returns to main loop 4. seeking event raised 5. currentTime reports 20 in seeking event handler This is the behaviour in Firefox 4. In every other browser I tested (Chrome 10, Opera 11, Safari 5, and Internet Explorer 9), the following behaviour is observed: 2. currentTime immediately reports 20 This doesn't seem to be required by the current wording of the spec (in fact, it seems to be incorrect behaviour), but I think this behaviour is more intuitive, as it seems unusual that currentTime returns to the old value immediately after being set and remains that way until the seeking event fires. Does it make sense to update the seeking algorithm to reflect how non-Firefox browsers are implementing this? My proposal is, effectively, to take steps 5 through 8 and insert them before step 4. I've uploaded a testcase to http://flim.org/~kinetik/seek-627139.html if anyone's curious. Thanks, -mjg There have been two non-trivial changes to the seeking algorithm in the last year: Discussed at http://lists.w3.org/Archives/Public/public-html/2010Feb/0003.html lead to http://html5.org/r/4868 Discussed at http://lists.w3.org/Archives/Public/public-html/2010Jul/0217.html lead to http://html5.org/r/5219 At least we (Opera) just haven't gotten around to updating our implementation yet. With that said, it seems like there's nothing that guarantees that the asynchronous section doesn't start running while the script is still running. It's also odd that currentTime is updated before the seek has actually been completed, but the reason for this is that the UI should show the new position. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Limiting the amount of downloaded but not watched video
On Thu, Jan 20, 2011 at 3:14 AM, Philip Jägenstedt phil...@opera.comwrote: However, it'd be great if all implementors could agree on the same interpretation of states. Specifically, this isn't required by the spec but would still be helpful to have consistency in: * effective state can only increase to higher states, never go from e.g. metadata to none (it makes no sense) * there is a state - invoked - between metadata and auto for when the video is playing * there could be a state between invoked and auto for autoplay, but if not autoplay implies preload=auto * in the invoked state, a conservative buffering strategy is used by default * when paused in the invoked state, we need to agree on what should happen I think that pausing shouldn't affect read-ahead buffering behavior. I'd suggest another preload value, preload=buffer, sitting between metadata and auto. In addition to everything loaded by metadata, it also fills the read-ahead buffer (whether the video is playing or not). - If a page wants prebuffering only (not full preloading), it sets preload=buffer. This can be done even when the video is paused, so when the user presses play, the video starts instantly without pausing for a server round-trip like preload=metadata. - If a page wants prebuffering while playing, but unlimited buffering when paused (per Zachary's suggestion), it sets preload=buffer when playing and preload=auto when paused. - As a more complex example, a page might use preload=metadata (or none) on an initially paused video, changing it to preload=buffer when playing, and to preload=auto if paused after playing. This minimizes bandwidth use if the video is never played (especially important if you have lots of videos on the same page), allows selecting whether the initially-paused state is metadata or none (depending on how much bandwidth you want to save), and uses Zachary's preload-only-when-paused only after the video has been played at least once and then paused again (eg. because the user noticed it was underrunning). -- Glenn Maynard
Re: [whatwg] Value of media.currentTime immediately after setting
On Jan 20, 2011, at 12:46 AM, Philip Jägenstedt wrote: On Thu, 20 Jan 2011 04:20:09 +0100, Matthew Gregan kine...@flim.org wrote: Hi, The media seek algorithm (4.8.10.9) states that the current playback position should be set to the new playback position during the asynchronous part of the algorithm, just before the seeking event is fired. This implies the following behaviour: 0. Initial load state (currentTime reports 0) 1. currentTime set to 20 by script 2. currentTime continues to report 0 3. Script returns to main loop 4. seeking event raised 5. currentTime reports 20 in seeking event handler This is the behaviour in Firefox 4. In every other browser I tested (Chrome 10, Opera 11, Safari 5, and Internet Explorer 9), the following behaviour is observed: 2. currentTime immediately reports 20 This doesn't seem to be required by the current wording of the spec (in fact, it seems to be incorrect behaviour), but I think this behaviour is more intuitive, as it seems unusual that currentTime returns to the old value immediately after being set and remains that way until the seeking event fires. Does it make sense to update the seeking algorithm to reflect how non-Firefox browsers are implementing this? My proposal is, effectively, to take steps 5 through 8 and insert them before step 4. I've uploaded a testcase to http://flim.org/~kinetik/seek-627139.html if anyone's curious. Thanks, -mjg There have been two non-trivial changes to the seeking algorithm in the last year: Discussed at http://lists.w3.org/Archives/Public/public-html/2010Feb/0003.html lead to http://html5.org/r/4868 Discussed at http://lists.w3.org/Archives/Public/public-html/2010Jul/0217.html lead to http://html5.org/r/5219 At least we (Opera) just haven't gotten around to updating our implementation yet. With that said, it seems like there's nothing that guarantees that the asynchronous section doesn't start running while the script is still running. It's also odd that currentTime is updated before the seek has actually been completed, but the reason for this is that the UI should show the new position. In WebKit this happens because currentTime isn't maintained in HTMLMediaElement (modulo the caching added in https://bugs.webkit.org/show_bug.cgi?id=49009), it is whatever the media engine (QuickTime, GStreamer, etc) reports. When currentTime is set the media engine is asked to seek immediately so the asynchronous section may run in parallel to the script, and therefore the seek may actually have completed by the time you check currentTime. eric
Re: [whatwg] Limiting the amount of downloaded but not watched video
On Thu, Jan 20, 2011 at 3:14 AM, Philip Jägenstedt phil...@opera.comwrote: * effective state can only increase to higher states, never go from e.g. metadata to none (it makes no sense) What if my bandwidth situation improves (moving from 3g to WiFi, for example)? At that point, perhaps I should go from auto to invoked? On Thu, Jan 20, 2011 at 4:19 AM, Glenn Maynard gl...@zewt.org wrote: I think that pausing shouldn't affect read-ahead buffering behavior. I'd suggest another preload value, preload=buffer, sitting between metadata and auto. In addition to everything loaded by metadata, it also fills the read-ahead buffer (whether the video is playing or not). Would the read-ahead buffer length be a configurable property? == New Proposal == Based on the feedback we've gotten, I'd like to propose the following: * Adding an additional preload state between metadata and auto (I'll call it state3, but we should name it invoked or buffer) * Adding the downloadTargetBuffer property, which can be updated at any time === Use cases === Starting with preload = none / meta * Once the user has indicated they want to play a video, the browser will go into state3 and buffer at least downloadTargetBuffer seconds of video before playing * Once in state3, the browser will attempt to maintain a buffer of approximately downloadTargetBuffer seconds, regardless of state * If the browser cannot maintain a buffer of length downloadTargetBuffer, it will set preload = auto * If preload is later set back to state3, the browser will: If the buffer = downloadTargetBuffer seconds: - The browser will play through the current buffer surplus until it has approximately downloadTargetBuffer seconds in the buffer - Once the surplus has been used, the browser will attempt to maintain a buffer of approximately downloadTargetBuffer seconds - If the browser cannot maintain a buffer of length downloadTargetBuffer, it will set preload = auto If the buffer downloadTargetBuffer seconds: - The browser will set preload = auto Starting with preload = state3 * On page load, the browser will go into state3 and buffer at least downloadTargetBuffer seconds of video before playing * Once the user has indicated they want to play a video, the browser will attempt to maintain a buffer of approximately downloadTargetBuffer seconds, regardless of state * If the browser cannot maintain a buffer of length downloadTargetBuffer, it will set preload = auto * If preload is later set back to state3, the browser will: If the buffer = downloadTargetBuffer seconds: - The browser will play through the current buffer surplus until it has approximately downloadTargetBuffer seconds in the buffer - Once the surplus has been used, the browser will attempt to maintain a buffer of approximately downloadTargetBuffer seconds - If the browser cannot maintain a buffer of length downloadTargetBuffer, it will set preload = auto If the buffer downloadTargetBuffer seconds: - The browser will set preload = auto Starting with preload = auto * On page load, the browser will go into auto and buffer as much video as possible * If preload is later set to state3, the browser will: If the buffer = downloadTargetBuffer seconds: - The browser will play through the current buffer surplus until it has approximately downloadTargetBuffer seconds in the buffer - Once the surplus has been used, the browser will attempt to maintain a buffer of approximately downloadTargetBuffer seconds - If the browser cannot maintain a buffer of length downloadTargetBuffer, it will set preload = auto If the buffer downloadTargetBuffer seconds: - The browser will set preload = auto Best, Zach -- Zachary Ozer Developer, LongTail Video w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 • f: 212.656.1335 JW Player | Bits on the Run | AdSolution
Re: [whatwg] Can we remove forminput and formchange events and related dispatch methods?
On 10/22/2010 10:09 PM, Jonas Sicking wrote: On Fri, Oct 22, 2010 at 11:15 AM, Erik Arvidssona...@chromium.org wrote: On Oct 22, 2010 2:00 AM, Anne van Kesterenann...@opera.com wrote: Yeah, I don't mind moving these features to libraries. Anyone implemented them apart from Opera? Neither WebKit nor Gecko implements it: https://bugs.webkit.org/show_bug.cgi?id=26141 https://bugzilla.mozilla.org/show_bug.cgi?id=605997 IE9 beta does not have it either. This means that we should also remove dispatchFormInput/dispatchFormChange from the HTML5 spec, right? / Jonas I agree, the events or at least the methods should be removed. -Olli
[whatwg] Browsers delay window.print() action until page load finishes
There seems to be no provision in the spec for a behavior Firefox and IE (and now WebKit-based browsers, too) have. If window.print() is called during page load, then its action is delayed until loading is finished. The WebKit bug that changed this most recently is https://bugs.webkit.org/show_bug.cgi?id=43658 - it has some information about trickier aspects of the behavior. This looks like something that needs to be formally specified. - WBR, Alexey Proskuryakov
Re: [whatwg] Limiting the amount of downloaded but not watched video
On 2011-01-20 19:16, Zachary Ozer wrote: == New Proposal == I like this. It seems you laid out everything to ensure a balanced buffer, kinda like a moving window buffer which I pointed out earlier. So as far as I can see, your proposal looks pretty solid, unless there are any implementation snafus. (looks at the Chrome, Safari, Opera, Firefox guys in the list (hmm, where's the IE guys?)) I really like the way you described the state3, and I think that would be my personal preference for playback myself. I assume JW player would be very quick at supporting/using it? -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] Limiting the amount of downloaded but not watched video
We never make any promises about when we'll get something into an official release, but I think we'd start playing around with it in our development version once a reference implementation was publicly available. -- Zachary Ozer Developer, LongTail Video w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 • f: 212.656.1335 JW Player | Bits on the Run | AdSolution On Thu, Jan 20, 2011 at 7:03 PM, Roger Hågensen resca...@emsai.net wrote: On 2011-01-20 19:16, Zachary Ozer wrote: == New Proposal == I like this. It seems you laid out everything to ensure a balanced buffer, kinda like a moving window buffer which I pointed out earlier. So as far as I can see, your proposal looks pretty solid, unless there are any implementation snafus. (looks at the Chrome, Safari, Opera, Firefox guys in the list (hmm, where's the IE guys?)) I really like the way you described the state3, and I think that would be my personal preference for playback myself. I assume JW player would be very quick at supporting/using it? -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] Limiting the amount of downloaded but not watched video
On Thu, Jan 20, 2011 at 1:16 PM, Zachary Ozer z...@longtailvideo.com wrote: On Thu, Jan 20, 2011 at 4:19 AM, Glenn Maynard gl...@zewt.org wrote: I think that pausing shouldn't affect read-ahead buffering behavior. I'd suggest another preload value, preload=buffer, sitting between metadata and auto. In addition to everything loaded by metadata, it also fills the read-ahead buffer (whether the video is playing or not). Would the read-ahead buffer length be a configurable property? ... * Adding the downloadTargetBuffer property, which can be updated at any time I don't think we've seen any use cases for directly configuring the read-ahead buffer size (downloadTargetBuffer). The closest to one that was mentioned is essentially to work around browser bugs: if a browser selects too small of a buffer, you can increase it. If this is configurable, then a default value (eg. null) should mean browser-determined, and people should be strongly encouraged to use it for prebuffering, not setting a specific number. * Once the user has indicated they want to play a video, the browser will go into state3 and buffer at least downloadTargetBuffer seconds of video before playing Be careful here: this greys the line between minimum prebuffer and maximum buffer size. That is, you may want to buffer up to 30 seconds of video, but to start playing after 5 seconds of video is buffered. The above means that if you set downloadTargetBuffer=30, the video won't start playing for a long time, since downloadTargetBuffer is doubling as both the minimum and maximum values. If the buffer downloadTargetBuffer seconds: - The browser will set preload = auto This is odd: you can't reset preload=auto to preload=state3 if less than downloadTargetBuffer is currently buffered. For example, if the user is implementing preload=auto only when paused, and downloadTargetBuffer is effectively 30 seconds, then pausing (and setting preload=auto) then unpausing (and resetting to preload=buffer) could cause preload to get stuck in auto. I think the approach of making preload a state variable is a bit odd. Here's an rough alternative proposal, which is based on leaving preload as a simple hint as it is now, and deriving downloadTargetBuffer from it: - downloadTargetBuffer is a derived (read-only) property that tells the browser the minimum amount it should attempt to prebuffer. This applies independently of any other state. - If preload=auto, downloadTargetBuffer value is infinity. - If preload=none or meta AND the video is paused, downloadTargetBuffer is zero. - In all other cases, downloadTargetBuffer is browser-determined as the amount necessary to play the video without underruns, and may change over time. If the browser determines that there's insufficient bandwidth to stream the video, downloadTargetBuffer is forced to infinity. (This is actually redundant with the previous line.) The minimum amount to buffer before playback can begin (eg. the transition from HAVE_CURRENT_DATA to HAVE_FUTURE_DATA) is unrelated to this proposal. We're only talking about maximum buffering, not minimum. If we want to allow the user to further influence downloadTargetBuffer, do so with separate non-derived properties (eg. minimumReadAhead). What if my bandwidth situation improves (moving from 3g to WiFi, for example)? At that point, perhaps I should go from auto to invoked? The above also addresses this. The browser's determination of whether you have enough bandwidth or not is reflected only in the value of downloadTargetBuffer. It can be increased or decreased however the implementation sees fit, eg. in response to having more bandwidth available (switching to WiFi), or in response to the server adjusting the bitrate of your stream. It's not clear to me that unclamping prebuffering is actually a meaningful response to having insufficient bandwidth, but this leaves that decision up to the implementation. -- Glenn Maynard
