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

[media-source] Restriction on not 'updating' in {set, clear}LiveSeekableRange is too strict

From: wolenetz via GitHub <sysbot+gh@w3.org>
Date: Wed, 13 Jul 2016 16:50:13 +0000
To: public-html-media@w3.org
Message-ID: <issues.opened-165369172-1468428611-sysbot+gh@w3.org>
wolenetz has just created a new issue for 
https://github.com/w3c/media-source:

== Restriction on not 'updating' in {set,clear}LiveSeekableRange is 
too strict ==
At least one MSE web author has reported that the step "If the 
updating attribute equals true on any SourceBuffer in sourceBuffers, 
then throw an InvalidStateError exception and abort these steps" in 
{set,clear}LiveSeekableRange makes the feature very hard to use and 
doesn't add value.

Consider the case where a live streaming app is appending small media 
segments independently to multiple SourceBuffers for one MediaSource, 
and the app wishes to tightly maintain the live seekable range. It's 
difficult for such an app to coordinate the calls to 
set/clearLiveSeekableRange to occur when 'updating' isn't in progress.
 Furthermore, the underlying usage of the "live seekable range" in the
 extended HTMLMediaElement.seekable logic itself makes no restriction 
on 'updating' not being in progress (nor should it).

This issue tracks removing the 'updating' check from 
{set,clear}LiveSeekableRange().

@jdsmith3000 I hope this doesn't constitute a substantive change -- it
 would be excellent if this issue were fixed in the current V1 CR 
time-frame. I'll prepare a candidate pull request for this today.

I'm triaging this to V1Editorial. Please speak up here if you disagree
 and believe this is substantive.

Please view or discuss this issue at 
https://github.com/w3c/media-source/issues/118 using your GitHub 
account
Received on Wednesday, 13 July 2016 16:50:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 13 July 2016 16:50:25 UTC