- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jun 2016 10:15:54 +0000
- To: public-html-media@w3.org
tidoust has just created a new issue for https://github.com/w3c/media-source: == Calling endOfStream after duration truncation may yield greater duration == The [Duration Change](http://w3c.github.io/media-source/#duration-change-algorithm) algorithm no longer links to the [Range Removal](http://w3c.github.io/media-source/#sourcebuffer-range-removal) algorithm (the change was made in response to issues #15 and #26, I think). The [End of Stream](http://w3c.github.io/media-source/#end-of-stream-algorithm) algorithm tells the user agent to update the duration to the _highest end time reported by the buffered attribute_. The intent seems to be to truncate the duration to the content effectively buffered. Am I right to assume that the track buffer ranges of a SourceBuffer remain untouched when the duration is truncated? If so, am I right to think that the duration may be set to a much larger value when `endOfStream()` is called as in the example below? ```javascript // Let's say mediaData holds 10s of media content var sourceBuffer = mediaSource.addSourceBuffer(mimeType); sourceBuffer.appendBuffer(mediaData); sourceBuffer.onupdateend = function () { // sourceBuffer.buffered.end(0) should now equal 10 // Truncating the duration no longer removes any buffered frame, // so sourceBuffer.buffered.end(0) should still equal 10 after next line mediaSource.duration = 2; // End of stream algorithm sets duration to the highest end time reported // by the buffered attribute, sourceBuffer.buffered.end(0) in this example mediaSource.endOfStream(); // mediaSource.duration should now equal 10. Is this the intended behavior? } ``` Please view or discuss this issue at https://github.com/w3c/media-source/issues/102 using your GitHub account
Received on Thursday, 23 June 2016 10:16:02 UTC