Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there a way to download metadata (duration) for all MediaItems in a playlist? #7978

Closed
strangesource opened this issue Sep 24, 2020 · 8 comments
Assignees
Labels

Comments

@strangesource
Copy link

Searched documentation and issues

StackOverflow, Issues, Documentation, Blog

Question

When loading/playing a playlist using the new playlist api introduced in 2.12.0, only data for the first item is loaded up until a few seconds before the transition to the next item happens. Window.durationMs from the second item stays C.TIME_UNSET until this point.

While this is perfectly fine for most applications, I do need the duration of all MediaItems in the playlist upon loading.

This leads me to the question if there is any way to configure the loading behaviour of a playlist to include the duration (manifest?) of all items right at the beginning?

@strangesource
Copy link
Author

I just found this:
SimpleExoPlayer.setUseLazyPreparation(false) but unfortunately it does not work for progressive sources. Is that a known limitation? 🤔

@marcbaechinger
Copy link
Contributor

marcbaechinger commented Sep 24, 2020

Yes, it's the intended default behaviour to prepare lazily. You can change this by setting

SimpleExoPlayer simpleExoPlayer = new SimpleExoPlayer.Builder(context)
    .setUseLazyPreparation(false)
    .build()l

in this case all media items are prepared as soon as you add them to the playlist. As soon as an media source that is created for an item has preparation completed, a onTimelineChanged event is sent to your app with TIMELINE_CHANGE_REASON_SOURCE_UPDATE. There is no guarantee in what order these events arrive. So if you have three (non-live stream) items in the playlist, you can wait until you receive three callback calls with TIMELINE_CHANGE_REASON_SOURCE_UPDATE and then you have all the durations in the timeline.

Like you mentioned, lazy preparation is enabled by default because this would cause an initial burst of network requests. If your playlist is short that may be acceptable for your app.

@marcbaechinger
Copy link
Contributor

:) We just cross posted. That should work though. That's not a known limitation. That would be a bug if not working. I'll look into that :)

@strangesource
Copy link
Author

Thanks for the fast answer!!! Much appreciated. I will have another look into the Issue I am having with the progressive source.

@marcbaechinger
Copy link
Contributor

I created a playlist with 4 items. With the default configuration the first two items are prepared initially (the media is quite short that's why the second item is prepared as well). But then it waits until playback advances to prepare the third and fourth item.

The third item is prepared after about 69 seconds:

timeline [eventTime=69.18, mediaPos=68.14, window=0, period=0, periodCount=4, windowCount=4, reason=SOURCE_UPDATE

When setting useLazyPreparation to false, all media sources are prepared immediately as expected:

mediaItem [eventTime=0.01, mediaPos=0.00, window=0, reason=PLAYLIST_CHANGED]
timeline [eventTime=0.23, mediaPos=0.00, window=0, periodCount=4, windowCount=4, reason=SOURCE_UPDATE
timeline [eventTime=0.24, mediaPos=0.00, window=0, period=0, periodCount=4, windowCount=4, reason=SOURCE_UPDATE
timeline [eventTime=0.28, mediaPos=0.00, window=0, period=0, periodCount=4, windowCount=4, reason=SOURCE_UPDATE
timeline [eventTime=0.77, mediaPos=0.00, window=0, period=0, periodCount=4, windowCount=4, reason=SOURCE_UPDATE
  period [128.27]
  period [135.65]
  period [59.30]
  ...
  window [128.27, true, false]
  window [135.50, true, false]
  window [59.18, true, false]

The logs (printed by EventLogger) show that all four SOURCE_UPDATEs arrived after 0.77 seconds when the media position is still on 0.0. The list of windows in the log is kept at a max of 3 but it shows that the durations are available already.

If you see a different behaviour, can you add the EventLogger to your app and do a bug report when you prepare your player and the upload this here so I can investigate?

@strangesource
Copy link
Author

I was able to reproduce my observed behaviour in the plain ExoPlayer with the these two MediaSource items:

        mediaItems = new ArrayList<>();
        mediaItems.add(MediaItem.fromUri("https://storage.googleapis.com/wvmedia/clear/h264/tears/tears.mpd"));
        mediaItems.add(MediaItem.fromUri("https://html5demos.com/assets/dizzy.mp4"));

And setUseLazyPreparation(false).

Duration is only available shortly before switching to the next source.

Here is the log you requested, hope that helps. 🙂
log.txt

@marcbaechinger
Copy link
Contributor

marcbaechinger commented Sep 24, 2020

Seems like my media was too short and my sample was misleading. Sorry about this. You are right. For progressive media sources, the first real media period needs to be prepared. This does not happen at the preparation time of the source. Only adaptive media have the duration available immediately at source preparation.

I'm sorry for any inconvenience caused. We have issue #4727 which covers this limitation already. It is marked as an enhancement for this. Like the comment here in the ProgressiveMediaSource.

@strangesource
Copy link
Author

Thanks @marcbaechinger, this helped me out a lot. The workaround propposed in the issue might work for us as well. 👍

@google google locked and limited conversation to collaborators Nov 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants