[Cast] Can live content start playing at live edge when cast session is already active?

[okycelt]

If live playback starts on device (starts correctly at live edge) and then switches to cast, it keeps playing in the correct position (more or less at the live edge). However, if live playback starts when cast session is already active it always starts at 0 (beginning of the live window, not at the live edge).

Is there a way to make live content start playing at the live edge when cast session is already active? We tried the following combinations, but no luck:

1. CastPlayer.setMediaItem(item) -> starts playing at 0
2. CastPlayer.setMediaItem(item, C.TIME_UNSET) -> starts playing at 0
3. CastPlayer.setMediaItem(item, Long.MAX_VALUE) -> renders first frame at live edge, but keeps buffering

Steps to reproduce in Exo Cast Demo

1. Start casting (with no item in the queue)
2. Add live content to the queue
3. Play live content (and it will start playing at position 0, not at the live edge)

ExoPlay version

2.15.0

Devices

Google Pixel 3a (API 30)

Sample content

Sent via email, but should be reproducible with any live content

[marcbaechinger]

I can confirm the behaviour you are describing.

When the stream is first played in ExoPlayer, playback is started at the default position (C.TIME_UNSET). This default position is resolved to an actual position in the live window by the media source (HlsMediaSource or DashMediaSource). This includes downloading the manifest (in case of DASH) or the master and media playlist (in case of HLS) to get the information needed for calculating the requested live latency and hence the start position.

When then playback is moved to the CastPlayer the current position is taken from the local ExoPlayer instance by the PlayerManager and sent as start position to the RemoteMediaClient.

If playback starts directly with the CastPlayer, C.TIME_UNSET is simply translated to 0.

We need to look into this to see how to improve this behavior of the receiver app. I can't give you a timeline for this I'm afraid. Sorry for not being able to give yo a better answer.

This is a long shoot as I haven't tested this yet: One thing you can try is creating your own MediaItemConverter and then map the media item in the same way as the DefaultMediaItemConverter, but use MediaInfo.STREAM_TYPE_LIVE instead of MediaInfo.STREAM_TYPE_BUFFERED.

[JonWatson]

This is a long shoot as I haven't tested this yet: One thing you can try is creating your own MediaItemConverter and then map the media item in the same way as the DefaultMediaItemConverter, but use MediaInfo.STREAM_TYPE_LIVE instead of MediaInfo.STREAM_TYPE_BUFFERED.

I can confirm that setting the Stream Type to STREAM_TYPE_LIVE does not fix this issue. Unset still results in beginning of Live stream being played rather than the Live edge

[marcbaechinger]

Did you play a live stream with Cast from the live edge before moving to CastPlayer of Media3? Like by using the Cast SDK API? What API did you use when using the Cast API directly to make this work?

[JonWatson]

My previous experience was with the Cast Companion library 5+ years ago. We used MediaLoadOptions.Builder().setPlayPosition. I can only speculate to the way the Receiver was written, and the assets were different, but I don't remember having a problem starting at the Live edge of a LIVE stream

[JonWatson]

I tried CastPlayer.setMediaItem(item, Long.MAX_VALUE) as @okycelt suggested and that did work for me. Starts very close to the live edge and I am not seeing a buffering issue