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

Lag in autoplay #14

Closed
rahulrj opened this issue Feb 18, 2016 · 4 comments
Closed

Lag in autoplay #14

rahulrj opened this issue Feb 18, 2016 · 4 comments

Comments

@rahulrj
Copy link

rahulrj commented Feb 18, 2016

Isnt there a lag in autoplay(SINGLE VIDEO SIMPLE LIST) when i scroll up and then scroll again down to the video. I think because prepare() is called again on that VideoView when i scroll back to it.

There is no case in which i just scroll back to the previous video and it plays without even a single millisecond delay. It always takes some time to prepare and resume the content.

@eneim
Copy link
Owner

eneim commented Feb 19, 2016

I would investigate this issue. But there is some points I could list out for the concern:

  • If a ViewHolder is out of the viewport, there is a high chance it got recycled. In that case, when you see the video again, it need to be bound to the data again, therefore, the Video got prepared again.
  • In single video list, I did not see the issue yet, so maybe it has something related to the Internet connection too. But if you could provide a gif file or a video demonstrate the issue it would be really helpful.

@rahulrj
Copy link
Author

rahulrj commented Feb 19, 2016

The first point is correct. It needs to be bound to data again. So there will always be slight lag.
I saw this issue in the sample app provided with this library running on WIFI. I will post the gif.
In a single video list also, this issue is bound to happen because the same recycling logic will happen if its a single or multiple video.

@rahulrj
Copy link
Author

rahulrj commented Feb 21, 2016

@eneim . It certainly performs better than the Android MediaPlayer. +1 for that.
But can you please let me know one thing? Using Toro, suppose i have a ListView and i have video at position 8 and 15. Now i watch video at position 8 and scroll down to position from there. Now if i scroll back to position 8, its a high chance that the view that i get there is a recycled view. So for position 8, i will have to set the data-source of the video again and then it will prepare again and start playing.

So how does Toro handles this prepare delay? Have you taken care of anything extra from Android Media Player to reduce this prepare time-delay?

If not, is it possible that i save partial-downloaded video(10 s out of 60s) in a local temp file and then play the video using that local file? In this way, i already have the partial downloaded content,so it wont take much time to prepare.

@eneim
Copy link
Owner

eneim commented Feb 22, 2016

@rahulrj I understand your need. As said, I try to keep Toro staying out of the core implementation of playback process. Playing video is hard, I can say. And there are many ways to do so (and each will give a slightly different cycle). In fact, I'm trying to research more about some popular playback libraries to improve my playback cycle and implementation. It could turns out to be an extension of Toro which will support the playback only.

For you case, I want to try to play a list of local video (called a Playlist). But before any implementation, I would like to ask how would you play your parts smoothly? I know about HLS which could provide a playlist of such small parts of a Video so that client could play it more effectively. But for a list of local part files (list of .mp4, I guess), I have no imagine of how it would work. If you can help me this, I can make up some ideas.

By the mean time, I think a proper way of caching the video locally could be a good solution. Take a look at this if it help (I have no idea for sure, but I will try too): AndroidVideoCache

@eneim eneim closed this as completed Mar 11, 2016
@eneim eneim reopened this Mar 11, 2016
@eneim eneim closed this as completed Apr 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants