Closed tonihei closed 4 years ago
The current thinking is that a seek will be handled as any other playback request by the user. Thus if the user seeks to a new position, a playbackRequested event should be generated, and when (potentially after some buffering) the content starts to play a playbackStarted is generated.
A scrub seek depends on the player implementation, but could in principle generate a number of playbackRequested events, possible followed (or intermixed) with a number of playbackStarted events.
WG agreed it would be beneficial to add a example graphic or amend an existing graphic and some text language in the spec.
Neel agreed to submit a proposal to WG for their review.
@njadia to propose event definition for "seek start" and "seek end" for WG to review.
Add the following event definitions in the table:
seekStart - Dispatched by media player when instructed to move playhead time to indicate media player began seeking. seekEnd - Dispatched by media player to indicate media player stopped seeking and has accumulated sufficient audio and video content in the buffer for playback.
@njadia Add the diagram (seek scenario) in the appendix & close comment.
Completed, please close.
WG agreed to Neel's proposed definitions and diagram.
Neither the list of events nor the examples given in the appendix describe how seeking is reported. I suppose it needs a new event for seekStart and can use playbackStart for the restart of playback after the seek has been handled and enough data has been buffered to continue playback. It would also be good to define what constitutes a single "seek" especially when considering scrubbing a seek bar or similar which can issue many seek operations on the underlying player.