W3C home > Mailing lists > Public > public-html-media@w3.org > June 2016

[media-source] Calling endOfStream after duration truncation may yield greater duration

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
Message-ID: <issues.opened-161887606-1466676954-sysbot+gh@w3.org>
tidoust has just created a new issue for 

== Calling endOfStream after duration truncation may yield greater 
duration ==
The [Duration 
algorithm no longer links to the [Range 
 algorithm (the change was made in response to issues #15 and #26, I 

The [End of 
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?

// Let's say mediaData holds 10s of media content
var sourceBuffer = mediaSource.addSourceBuffer(mimeType);
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 
  mediaSource.duration = 2;

  // End of stream algorithm sets duration to the highest end time 
  // by the buffered attribute, sourceBuffer.buffered.end(0) in this 

  // mediaSource.duration should now equal 10. Is this the intended 

Please view or discuss this issue at 
https://github.com/w3c/media-source/issues/102 using your GitHub 
Received on Thursday, 23 June 2016 10:16:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:09 UTC