[media-source] Consider adding API for app to get the PTS of the GOP containing currentTime

wolenetz has just created a new issue for 
https://github.com/w3c/media-source:

== Consider adding API for app to get the PTS of the GOP containing 
currentTime ==
MSE apps that wish to use remove() can encounter problems if they 
attempt to remove the currently-decoding-and-playing GOP: at a 
minimum, disrupted continuous playback can result.

Can we do better? I believe so :)

Some ideas I have around this (certainly incomplete, meant as a 
discussion starting point):
* Add a SourceBuffer method to retrieve the earliest PTS of coded 
frames in the GOP containing currentTime. The app could then use the 
result to ensure that a later remove() operation doesn't include the 
GOP that was currently being played. This approach has a few 
complications:
  * An app that wished to use it effectively would probably need to 
ensure that playbackRate >= 0, e.g., the playback is not going 
backwards. In many user agents, reverse playback of HTMLMediaElement 
is not currently enabled.
  * currentTime, while playing and playbackRate > 0, is always 
increasing, so the "current GOP" may change to a later one between 
calling this proposed API and the eventual remove(). This just means 
that less is removed, and the GOP underlying the play-head remains 
undisturbed (if the app doesn't remove it, of course).
  * Even if paused or playbackRate <= 0, this API should still give 
the earliest PTS of coded frames in the GOP containing currentTIme. 
(Perhaps we might change this such that if playbackRate is strictly < 
0, the API instead returns the highest ending presentation time of the
 GOP containing currentTime?)
* And/or make remove() have an overload with an optional parameter 
that lets the app optionally request the remove() operation to not 
actually do the remove if the remove would remove the GOP currently 
being decoded and played, and instead give some exception - perhaps 
with some indication of the earliest or latest PTS (depending on 
playbackRate>=0 or not) of coded frames in the currently 
decoding+playing GOP.
  * This alternative would alleviate all 3 of the complications listed
 for the first alternative, above.

I'd really welcome other proposals for how to alleviate this MSE web 
application difficulty.
@jdsmith3000 @mwatson2 FYI - please chime in.

Please view or discuss this issue at 
https://github.com/w3c/media-source/issues/173 using your GitHub 
account

Received on Wednesday, 30 November 2016 23:52:13 UTC