We could offer precision seeking in Letterbox view.
A while ago, we were resuming playback after seeking while paused, on iOS. We changed this behavior, not resuming playback in such cases, as Youtube does. Android kept the original behavior.
Now that we integrated seek bar support in the control center, I felt something was wrong with the iOS behavior. Why would the user seek just for the sake of seeking? In general, we should expect the user to want to play the content, so why shouldn't we always resume playback after an interactive seek?
In discussing with people, it appears there might be a use case for video, namely if you want to search a specific video frame or to search without sound playing. This kind of experience requires better player capabilities that what we currently have:
Seek previews (see #187).
Precision seeking (e.g. like what Apple does when you increase the distance between your finger and the slider). The player would then need to seek with no tolerance in such cases, so that the proper frame is reached.
For audio and video in the control center (we should also discuss the behavior we want for AirPlay), it seems that seeking interactively should always resume playback. For video, since we currently miss the above features, having the same behavior makes sense, as there is no way to reach a specific frame anyway. This is how we fixed the iOS implementation, thus aligning it with Android.
Once we have implemented the above features, we could discuss the following behavior, and implement it if this makes sense:
For audio and content in the control center, always resume playback after seeking while paused.
For video visible on screen, do not resume playback when seeking while paused.
Apple has removed precision seeking from its modern player user interface. Precision seeking as well as step by step seeking (for content which has been buffered or supports stepping) is available in Pillarbox, Letterbox successor, though. Closed.
We could offer precision seeking in Letterbox view.
A while ago, we were resuming playback after seeking while paused, on iOS. We changed this behavior, not resuming playback in such cases, as Youtube does. Android kept the original behavior.
Now that we integrated seek bar support in the control center, I felt something was wrong with the iOS behavior. Why would the user seek just for the sake of seeking? In general, we should expect the user to want to play the content, so why shouldn't we always resume playback after an interactive seek?
In discussing with people, it appears there might be a use case for video, namely if you want to search a specific video frame or to search without sound playing. This kind of experience requires better player capabilities that what we currently have:
For audio and video in the control center (we should also discuss the behavior we want for AirPlay), it seems that seeking interactively should always resume playback. For video, since we currently miss the above features, having the same behavior makes sense, as there is no way to reach a specific frame anyway. This is how we fixed the iOS implementation, thus aligning it with Android.
Once we have implemented the above features, we could discuss the following behavior, and implement it if this makes sense: