Open iamkbkarthikeyan opened 2 months ago
Hi @iamkbkarthikeyan, the caching is handled in background only.
Can you try it with the plain video_player plugin and see if you get any different results.
Hi @OutdatedGuy,
Thanks for your reply. The caching mechanism is working well, but I’ve noticed that the initialization process takes 3-6 seconds the first time, and occasionally up to 10-15 seconds. I’m developing a shorts-style app that involves multiple video players, so reducing this initialization time is crucial.
If there’s a way to leverage streaming or buffering, I believe we could reduce this delay. As you mentioned, the solution might lie in the Original Video Player. I’ll review the package again and get back to you. If I come up with any ideas for improvement, we can consider implementing them in our package.
Cheers, KB
Some LRU caching or buffered caching is there in exoplayer which requires native code changes but that could be advantageous in my opinion. What do you guys think @iamkbkarthikeyan @OutdatedGuy
i haven't used this package yet but i had similar experience trying to use the video_player and flutter_cache_manager. the time it takes to download then cache is extremely long. I tried HLS videos but it didn't improve anything. I also tried isolates but you cant cache files in anything except the main thread. The only solution is to use native code to start another thread where you can do the caching. that way load times for a video would be 5 seconds or less on the first run, then within a second on future loads, since you will be loading from the cache.
@sagnik-sanyal Hi, I'm not familiar with either native Android or iOS codes. So I cannot really implement it.
But if you can PRs are always welcomed 😄
@iceekreeam the way this package works is if there is no cache available, the package starts caching the video in background and initializes the video from network directly, else the cache is used.
Also, what I have found with some testing is that the larger the video from network the more time it takes for the base video_player
plugin to initialize it.
@iceekreeam the way this package works is if there is no cache available, the package starts caching the video in background and initializes the video from network directly, else the cache is used.
Also, what I have found with some testing is that the larger the video from network the more time it takes for the base
video_player
plugin takes to initialize it.
Hey @OutdatedGuy if it actually caches in the background then this might be the solution i was looking for. i'll try it out at some point. Just not sure how you managed that if the download and cache are running on the main thread. My experience was really slow using flutter cache manager to the point that i removed caching from my app until i could resolve this issue. Anyways happy to try it out and give feedback.
@iceekreeam the way this package works is if there is no cache available, the package starts caching the video in background and initializes the video from network directly, else the cache is used.
Also, what I have found with some testing is that the larger the video from network the more time it takes for the base
video_player
plugin takes to initialize it.
Hey @OutdatedGuy is that mean each video getting downloaded twice?
@Yaronkr unfortunately yes. Unless we can find a way to cache the already downloaded data from network, it has to download the video twice
@OutdatedGuy Better player plugin has caching functionality can you confirm is it what that we want for our usecase so that we can integrate similar functionality for this plugin?
I'm curious if we are alluding to the same problem. because the the caching and downloading makes the initialization with flutter_cache_manager a lot longer. the downloading twice would explain it. when you say "caching in the background" can you explain that? are you using multithreading?
@sagnik-sanyal I'll look into it and let you know once I'm free.
@iceekreeam sorry for the confusion, by background I meant Asynchronously in the main thread, not in a separate isolate.
@OutdatedGuy ok so that gives me more confidence in saying that the second download is slowing the initalization too much. which can make a 3 second download appear like 6 to 10 seconds or more (when no cache exists). i tested with and without caching and the speeds are massively different. So my recommendation goes back to my initial comment. If you can't avoid the second download, then a native ios functionality needs to do the caching in another thread. (I couldn't get isolates to access the fs). Is your team able to do that?
@OutdatedGuy Any updates on this one? i'm hoping to avoid learning ios/swift development to get around this issue lol
@iceekreeam I'm busy with work hence cannot look into it currently. However, PRs are always welcomed.
Hi @OutdatedGuy, I am using this package from the last two months. It's working well. But, I recently noticed when my android app handles large video file from the network then it took more time for init the video. I think it is downloading and caching then initialise the video. So, if there is something like buffering/streaming while downloading will be the added advantage for this package. It improves user experience. also, we can keep the caching part in the background task once it gets completed.
Thanks in advance!