- 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