- From: wolenetz via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Nov 2016 23:52:04 +0000
- To: public-html-media@w3.org
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