Allow playlist items to specify a start position

[thorbenprimke]

[REQUIRED] Use case description

The use case for initialSeekTime is for creating / restoring a playlist or queue in which more than one item has an initial seek.
The initial seek is the time that the item was previously paused at. The reason for more than one is that the queue is re-arrangeable and thus an item with an initial seek from position 0 could be moved to position 1 and the item in position 0 is played but also paused. Thus when recreating the playlist, two mediaSource items need an initial seek time.

Proposed solution

I have hacked up a solution where I pass in an initial seek time by setting a new defaultStartPositionUs in the ProgressiveMediaSource. This achieves the desired result but I'm not certain that is necessarily correct or what things this may break (outside of working as expected in the playlist example in the demo app).

Here is a video. You can see the first item in the playlist plays from the 20 second mark and the next item starts from the 16 seconds mark.

Perhaps the right solution may be to create a class similar to ClippingMediaSource that wraps another MediaSource. This wrapping media source could then set the windowDefaultStartPositionUs in the Timeline.

Alternatives considered

• I have tried to use seekTo before prepare but this only works for the first item in the playlist.
• I have also tried to use the onPositionDiscontinuity callback. This works for both the first and subsequent items in the playlist. However due to the onPositionDiscontinuity being a callback, the subsequent items in the playlist always play for some milliseconds before the seek is initiated (in onPositionDiscontinuity) and thus there is an audible play-buffering-play.

Thanks for taking a look at this feature request. I would appreciate any feedback in regards to the proposed solution and if you think that creating a wrapping MediaSource to enable the initial seek would fit with the overall architecture of Exoplayer / MediaSources.

[andrewlewis]

@tonihei Please could you take a look at this?

[tonihei]

We talked about this feature request recently and decided that we probably need a way to specify a start position for a playlist item that is not the first to be played [internal ref: b/138782031]

The approach you mention above of writing a MediaSource wrapper and a Timeline wrapper to override the windowDefaultStartPositionUs works to set the start position for all cases. However, this is very complicated given the simple request and it's also not the "default" position of the media. If you need such a feature immediately, you should probably go down this route as it is the only reliable way to do this right now. If you need guidance, it's probably best to look at other MediaSource wrappers like MergingMediaSource or LoopingMediaSource to see what needs to be done.

Our suggested new implementation will distinguish between a "start position" and "default position":

• "start position" is the position at which playback starts when transitioning automatically in a playlist. This needs to be easily configurable when adding an item to the playlist. Something like addMediaItem(newItem, startPositionMs). That's what you like to change here and is often used when resuming playback from a previous position.
• "default position" is a property of the media itself (basically the current windowDefaultStartPositionUs parameter) that specifies where media needs to start if nothing else is specified. Live streams for example usually have a non-zero default position to start close to the live edge. That value doesn't need to be changed and shouldn't be changed and will be used, for example, when calling seekToDefaultPosition or when repeating a media item.

[Debayudh]

@tonihei
Is there any way to achieve this when using MediaItem ?
We are now using MediaItems instead of MediaSource, and don't see any way to set start time for setting start time of Items after the first.
Tried using setClipStartPositionMs , but we don't want to take away user's ability to seek back to portions of video he has already watched (this would probably also skew our custom seekbar, so best avoided).

[tonihei]

This is still an open feature request and not implemented yet. The only way to achieve something similar for now is the workaround with the custom wrapping MediaSource as described above.

[martinmidtsund]

@tonihei Hi, is the current status on this the same as in september '21, regarding your suggested new implementation from '19? :)

[tonihei]

I'm afraid the current status is still the same. Note that we will soon merge #10446 (solving #7279), which should simplify the implementation of the workaround I suggested above.