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

how to avoid small laggy when call player.next () in a playlist #8273

Closed
yangcheng opened this issue Nov 24, 2020 · 4 comments
Closed

how to avoid small laggy when call player.next () in a playlist #8273

yangcheng opened this issue Nov 24, 2020 · 4 comments

Comments

@yangcheng
Copy link

I have a play list of videos, which are of irregular length. I want to jump to next() on a fixed interval, otherwise I'd like it loop though a subset of list.

consider the following example, a playlist contain videos between 5-10 seconds long, I'd like to go to a new video at exactly 60 seconds , so it might be possible that some video are just starting, and I need the next one to play. I am using player.next() however, it's causing a small laggy.
Is there a way to make the transition smooth? like at 59 seconds, tell the player to start caching next video

thanks

@AquilesCanta
Copy link
Contributor

Hi @yangcheng,

tell the player to start caching next video

In ExoPlayer there's no way to individually control buffering for each item. You need to put the items in a playlist and let the player handle the buffering for you. And the player will start buffering the next item only after it has finished buffering the current one.

As things stand now, the only way of loading content from a following item without fully loading the current one is by clipping the current item, so that the player doesn't buffer it fully. Clipping content dynamically is tracked by #3163. I am guessing you can't use ClippingMediaSource because depending on user interactions you may want to play the full video. Is this right?

@AquilesCanta
Copy link
Contributor

Thanks to @tonihei for pointing this out. There's also #3327 which seems to track exactly what you are asking for.

Other than implementing some form of local cache manually, I think your best option is tracking #3327.

If there's any aspect of your question unanswered, please let me know and I'll reopen the issue.

@yangcheng
Copy link
Author

thanks for pointing out ClippingMediaSource, the only user interaction I need to support is pause and resume, no need for seekbar control. so I guess I can use it?

@AquilesCanta
Copy link
Contributor

so I guess I can use it?

Certainly seems so. Please give it a try!

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

No branches or pull requests

3 participants