This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#source-buffer-duration-updates In this section (which should be non-normative) it says that "Any time a media segment that goes beyond the current value of the duration attribute is appended to a SourceBuffer, the duration attribute will get updated to end timestamp of the media segment." (Note also that this should be scoped to only implicit duration, but the section nesting doesn't make it so.) http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#dom-append This section says "Update the duration attribute to reflect the end of the appended data. (ie Highest end timestamp reported by HTMLMediaElement.buffered)" This looks like it's assuming that segments are always appended in order. Should be rephrased to set duration to the maximum of the current duration and the end timestamp of the appended segment.
(In reply to comment #0) > http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#source-buffer-duration-updates > > In this section (which should be non-normative) it says that "Any time a media > segment that goes beyond the current value of the duration attribute is > appended to a SourceBuffer, the duration attribute will get updated to end > timestamp of the media segment." > > (Note also that this should be scoped to only implicit duration, but the > section nesting doesn't make it so.) I don't quite understand what you are saying here. The explicit vs implicit difference is only how the duration is set. The intent is not to maintain 2 different values. All four sections under 2.12 are intended to change the same underlying duration value. Are you saying the duration set via append() is just another form of implicitly setting the duration and therefore should be part of 2.12.2? > > http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#dom-append > > This section says "Update the duration attribute to reflect the end of the > appended data. (ie Highest end timestamp reported by > HTMLMediaElement.buffered)" > > This looks like it's assuming that segments are always appended in order. > Should be rephrased to set duration to the maximum of the current duration and > the end timestamp of the appended segment. That was not the intent. Maybe this is a little clearer "Update the duration attribute to the maximum of the current duration and the highest end timestamp reported by HTMLMediaElement.buffered." I just realized the spec doesn't define how SourceBuffer.buffered maps to HTMLMediaElement.buffered so I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=18615 . If that proposal is accepted, the new text above is slightly different then what you proposed. If that definition of HTMLMediaElement.buffered was used then duration would only change when the playable region changed not when a segment was appended to a single SourceBuffer.
(In reply to comment #1) > (In reply to comment #0) > > http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#source-buffer-duration-updates > > > > In this section (which should be non-normative) it says that "Any time a media > > segment that goes beyond the current value of the duration attribute is > > appended to a SourceBuffer, the duration attribute will get updated to end > > timestamp of the media segment." > > > > (Note also that this should be scoped to only implicit duration, but the > > section nesting doesn't make it so.) > > I don't quite understand what you are saying here. The explicit vs implicit > difference is only how the duration is set. The intent is not to maintain 2 > different values. All four sections under 2.12 are intended to change the same > underlying duration value. > > Are you saying the duration set via append() is just another form of implicitly > setting the duration and therefore should be part of 2.12.2? OK, I see now that 2.12.3 is actually consistent with how append() is spec'd. I assumed that an explicit duration was final, but apparently the order of setting an explicit duration and appending influences the result: * When first appending data and then setting the duration, data after duration is discarded. * When first setting the duration and then appending data, the duration is modified instead of discarding data. I suppose this makes some sense, but I doubt it will be obvious to users of the API why shuffling the code around a bit has this effect. I have no suggestion for improvement at this point. > > http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#dom-append > > > > This section says "Update the duration attribute to reflect the end of the > > appended data. (ie Highest end timestamp reported by > > HTMLMediaElement.buffered)" > > > > This looks like it's assuming that segments are always appended in order. > > Should be rephrased to set duration to the maximum of the current duration and > > the end timestamp of the appended segment. > > That was not the intent. Maybe this is a little clearer > > "Update the duration attribute to the maximum of the current duration and the > highest end timestamp reported by HTMLMediaElement.buffered." Yes, that is unambiguous and clear.
Changes committed. http://dvcs.w3.org/hg/html-media/rev/340786fcae83 - Clarified text for duration updates triggered by appending past the end. - Removed section 2.12 since it was non-normative. - Created a new normative duration change algorithm. (Section 3.3.6) - Updated append(), endOfStream(), & duration setter algorithms to use the new duration change algorithm. Let me know if there are problems with the new text. I think it is a lot clearer and now it points to the actual parts of the HTML spec that deal with duration changes.
Looks good, but the first step of the MSE duration change algorithm should be aborting if the new duration is the same as the old duration, since running the HTMLMediaElement duration change algorithm when the duration has not change doesn't make sense, and would fire a spurious durationchange event.
Changes committed. http://dvcs.w3.org/hg/html-media/rev/ca093bbbbefb