27790 2015-01-09 02:47:49 +0000 [MSE] Some of the attributes returning TimeRanges objects seem to return a new object each time the getter is invoked 2015-10-13 22:54:54 +0000 1 1 1 Unclassified HTML WG Media Source Extensions unspecified PC All RESOLVED MOVED P2 normal CR 1 bzbarsky wolenetz acolwell b.gajda d jyavenard mike philipj public-html-media public-html-bugzilla oldest_to_newest 116940 0 bzbarsky 2015-01-09 02:47:49 +0000 For example, the definition of SourceBuffer.buffered says: "Let intersection ranges equal a TimeRange object containing a single range from 0 to highest end time." This seems to create new object each time someone does .buffered. This is a pretty bizarre behavior. If we actually want a new object each time, this should be a method, not an attribute. 116955 1 philipj 2015-01-09 09:41:20 +0000 This follows the behavior of HTMLMediaElement.buffered/played/seekable, so maybe file an HTML bug if you want some change there. 116957 2 bzbarsky 2015-01-09 11:54:48 +0000 That HTML/WHATWG bug has existed for a while and been ignored. Basically, Ian thinks it's not an issue in WHATWG because he tends not to care too much about consistency with JS author expectations, the HTML WG is not aiming to change things like this from the WHATWG spec (though this is a case where sanity via the HTML WG might have been nice), and as far as I can tell the TAG hasn't really been looking very closely at HTML, because it's too big, so here we are. Changing this for HTMLMediaElement is also harder because those bits have been shipping in browsers for a good long while now... But just because the HTML situation is broken due to the politics around HTML and possible legacy compat issues doesn't mean we should be spreading the brokenness further to new specs, imo. 116958 3 bzbarsky 2015-01-09 12:51:44 +0000 In particular, see the discussion in bug 22471 where the suggestion that we stop doing the bad thing was just summarily ignored and all the conversation centered around how we prevent other specs from copying the bad thing.... 116962 4 philipj 2015-01-09 13:27:11 +0000 Thanks, bug 22471 was the discussion I wasn't sure had happened. I'm not the spec editor here, but my take is that returning a new object every time isn't terrible enough to warrant trying to replace the attribute with a method, it's too late for HTMLMediaElement and consistency is worth something as well, even when consistently bad. Ensuring that .buffered returns the same object as long as it hasn't changed since last access would be a less radical change that's probably Web compatible, if both specs made the same change. I'm also OK with the current state of things. 116964 5 bzbarsky 2015-01-09 14:13:09 +0000 > my take is that returning a new object every time isn't terrible enough It's pretty terrible. It's a behavior that only C++ implementors seem to think is OK for a JS property get.... Not least because it's simple for them to do. > Ensuring that .buffered returns the same object as long as it hasn't changed > since last access Can it change without the event loop spinning or script in some way invoking browser APIs? Because if not, then this is clearly the correct solution, imo. 116972 6 acolwell 2015-01-09 19:52:33 +0000 I'm fine with changing SourceBuffer.buffered to return the same object all the time. Technically these values can only change as part of the "Coded Frame Removal" and "Coded Frame Processing" algorithms. I'm assuming that you want the value to be stable as long as webapp Javascript is executing. Is this usually handled by using language like "post a task to update the buffered attribute with the contents of intersection_ranges"? If not, could you point me at a good example in other specs. The spec text that describes always creating a new object for access HTMLMediaElement.buffered probably needs to remain though so that the behavior is consistent with non-MSE playback. 116974 7 bzbarsky 2015-01-09 20:05:06 +0000 > Is this usually handled by using language like "post a task to update the > buffered attribute with the contents of intersection_ranges"? Yep, this would work fine. Just have to say which task queue to post it to. Thank you! For HTMLMediaElement, that would be bug 22471, so let's not worry about it here. 117016 8 philipj 2015-01-12 10:59:45 +0000 (In reply to Boris Zbarsky from comment #5) > > my take is that returning a new object every time isn't terrible enough > > It's pretty terrible. It's a behavior that only C++ implementors seem to > think is OK for a JS property get.... Not least because it's simple for > them to do. Guilty as charged, I didn't even consider this problem when implementing these properties in Presto. > > Ensuring that .buffered returns the same object as long as it hasn't changed > > since last access > > Can it change without the event loop spinning or script in some way invoking > browser APIs? Because if not, then this is clearly the correct solution, > imo. I think that's true for MediaSource as the append/remove bits are all async. HTMLMediaElement can synchronously detach from its backend by e.g. HTMLMediaElement.load(), but that's in response to an explicit call. I can think of no way 'video.buffered === video.buffered' to ever be false with a definition like "return the same object iff the ranges are identical to the previously returned object." I don't think MSE should do this if HTML doesn't, though. Always returning the same object and having that be live is also possible, but I'm not a fan of live objects, and it could possibly break existing code that keeps old ranges in order to compare with new ones. 117073 9 b.gajda 2015-01-13 14:36:48 +0000 (In reply to Aaron Colwell from comment #6) > Technically these values can only change as part of the "Coded > Frame Removal" and "Coded Frame Processing" algorithms. Just to be clear - value reported to user is also affected by changing MediaSource readyState state to ended/from ended to open, in cases with 2 track buffers with different buffered regions. Example: trackbuffer1: 3-5; trackbuffer2: 7-10; returns buffered 7-10 in ended state, empty range in open. 117081 10 acolwell 2015-01-13 16:35:20 +0000 Boris, Would just changing the spec to return the same object if the ranges haven't changed, as Philip suggest, be sufficient? I'm worried about making this attribute a live object for the following reasons: 1. It would become inconsistent with HTMLMediaElement.buffered behavior. I know you don't like this, but I think there is something to be said for keeping all TimeRanges attributes in the web platform behaving the same way especially if they are highly related like the .buffered attributes are. 2. This is one of the oldest parts of the MSE spec and is likely to break sites including large deployments like YouTube and Netflix for seemingly only aesthetic gain. 3. There is no simple way for the web app to make its own copy. The TimeRanges object doesn't have a way to clone itself so all web applications that wanted to keep a copy have to implement their own cloning logic. 117082 11 bzbarsky 2015-01-13 16:40:45 +0000 > Would just changing the spec to return the same object if the ranges haven't > changed, as Philip suggest, be sufficient? Yep. I said so in comment 5, right? > I'm worried about making this attribute a live object Sure. I think the compat worries are well-justified, live objects are a pain to work with, and we don't need to go there. 117083 12 acolwell 2015-01-13 16:43:13 +0000 (In reply to Boris Zbarsky from comment #11) > > Would just changing the spec to return the same object if the ranges haven't > > changed, as Philip suggest, be sufficient? > > Yep. I said so in comment 5, right? Ok. It wasn't clear to me. > > > I'm worried about making this attribute a live object > > Sure. I think the compat worries are well-justified, live objects are a > pain to work with, and we don't need to go there. Agreed. I'll make the changes in the next spec update then. Thanks. :) 117675 13 acolwell 2015-02-03 18:59:02 +0000 Change committed... https://github.com/w3c/media-source/commit/7a495fe29540835d0e219d3d52f3041f556a1f7d 119187 14 jyavenard 2015-04-02 00:44:22 +0000 While this bug clearly describe that we should only return the same object (same reference) only if it hasn't changed. And so is the summary: "Bug 27790 - Make .buffered attributes return the same object if nothing has changed." is very clear. I find the actual description of the buffered attribute however to not be reflecting this. "5. If intersection ranges does not contain the exact same range information as the current value of this attribute, then update the current value of this attribute to intersection ranges. 6. Return the current value of this attribute. " I read this as always returning the same TimeRange object, and updating the object. Making it effectively a "live" object as described in comment 10. 119188 15 acolwell 2015-04-02 01:13:17 +0000 (In reply to Jean-Yves Avenard from comment #14) > While this bug clearly describe that we should only return the same object > (same reference) only if it hasn't changed. > > And so is the summary: > "Bug 27790 - Make .buffered attributes return the same object if nothing has > changed." > > is very clear. > > I find the actual description of the buffered attribute however to not be > reflecting this. > "5. If intersection ranges does not contain the exact same range > information as the current value of this attribute, then update the current > value of this attribute to intersection ranges. > 6. Return the current value of this attribute. > " > > I read this as always returning the same TimeRange object, and updating the > object. Making it effectively a "live" object as described in comment 10. That was not the intent. Please suggest some alternate text that would make step 5 clearer to you. 123689 16 wolenetz 2015-10-13 22:54:54 +0000 This bug has been migrated to the GitHub issue tracker. Please follow/update progress using the GitHub issue: https://github.com/w3c/media-source/issues/16 In particular, Jean-Yves Avenard, do you have a suggestion for improved text? (Please respond on the GitHub issue.)