media icon indicating copy to clipboard operation
media copied to clipboard
verified publisher icon androidx

How to increase download speed with ExoPlayer downloader

Open rdutta2020 opened this issue 6 months ago • 4 comments

  • We are using ExoPlayer 2.15.1 version
  • Widevine encrypted content (HLS or DASH)
  • Parallel Download permitted = 1, so we cannot download multiple items at a time

We would like to know if we can change any configuration in Downloader which can make the download faster ? We have already tried by by increasing number of thread in DownloadManager / DownloaderFactory / Executor but it did not work. Even through we provided more number of threads in executor passed to DownloaderFactory, we see that during content download only 2 threads run with ExoPlayer name (ExoPlayer:DownloadManager and ExoPlayer:FrameReleaseChoreographer).

Please help us how we can increase download speed (Exoplayer configurations) ?

rdutta2020 avatar Jul 02 '25 08:07 rdutta2020

@rdutta2020,

I had some trouble to try with ExoPlayer 2.15.1 though, I don't think this part of logic has changed drastically since then. Thus with the latest media3 version -

I downloaded a DASH media on demo app, where we have a thread pool Executor with 6 threads https://github.com/androidx/media/blob/ae9a2339679826f870690092509a135dffc0d7e4/demos/main/src/main/java/androidx/media3/demo/main/DemoUtil.java#L168-L174

With some logs manually added in the SegmentDownloader, I'm seeing that the segments are downloaded across each threads in the pool

2025-07-04 15:35:48.478 20044-20131 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 0 on thread Thread[pool-4-thread-4,5,main]
2025-07-04 15:35:48.479 20044-20132 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 24000000 on thread Thread[pool-4-thread-5,5,main]
2025-07-04 15:35:48.480 20044-20133 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 48000000 on thread Thread[pool-4-thread-6,5,main]
2025-07-04 15:35:48.481 20044-20128 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 72000000 on thread Thread[pool-4-thread-1,5,main]
2025-07-04 15:35:48.481 20044-20129 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 96000000 on thread Thread[pool-4-thread-2,5,main]
2025-07-04 15:35:48.481 20044-20130 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 120000000 on thread Thread[pool-4-thread-3,5,main]
2025-07-04 15:36:08.556 20044-20131 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 144000000 on thread Thread[pool-4-thread-4,5,main]
2025-07-04 15:36:14.821 20044-20133 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 168000000 on thread Thread[pool-4-thread-6,5,main]
2025-07-04 15:36:19.477 20044-20129 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 192000000 on thread Thread[pool-4-thread-2,5,main]
2025-07-04 15:36:19.496 20044-20130 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 216000000 on thread Thread[pool-4-thread-3,5,main]
2025-07-04 15:36:20.096 20044-20128 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 240000000 on thread Thread[pool-4-thread-1,5,main]
2025-07-04 15:36:20.187 20044-20132 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 264000000 on thread Thread[pool-4-thread-5,5,main]
2025-07-04 15:36:36.512 20044-20131 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 288000000 on thread Thread[pool-4-thread-4,5,main]
2025-07-04 15:36:43.871 20044-20133 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 312000000 on thread Thread[pool-4-thread-6,5,main]
2025-07-04 15:36:48.809 20044-20130 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 336000000 on thread Thread[pool-4-thread-3,5,main]
2025-07-04 15:36:48.822 20044-20129 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 360000000 on thread Thread[pool-4-thread-2,5,main]
2025-07-04 15:36:48.838 20044-20128 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 384000000 on thread Thread[pool-4-thread-1,5,main]
2025-07-04 15:36:49.038 20044-20132 GithubDebug             androidx.media3.demo.main            W  Download segment with start time 408000000 on thread Thread[pool-4-thread-5,5,main]

But by simply using Executors.newFixedThreadPool(/* nThreads= */ 6), the threads are not named with ExoPlayer. Could you please provide the details on what Executor instance you configured with, or maybe it's just an thread naming thing?

tianyif avatar Jul 04 '25 18:07 tianyif

I configured with "Executors.newFixedThreadPool()" only. As you have pointed out, that may be the reason behind threads are not named with "ExoPlayer".

Also changing the value i.e. "Executors.newFixedThreadPool(/* nThreads= / 6)" to "Executors.newFixedThreadPool(/ nThreads= */ 20)" did not increase the download speed for me.

Now the actual question is on how to increase download speed in ExoPlayer Downloader ? Can I get some guidance from this forum ?

rdutta2020 avatar Jul 08 '25 09:07 rdutta2020

@tianyif @microkatz Can we get any update please ?

rdutta2020 avatar Jul 21 '25 05:07 rdutta2020

@rdutta2020,

I think simply adding more threads to download doesn't necessarily to increase the download speed. I mean, it can be bottlenecked by your network bandwidth and how large your segments are.

I took some experiments on the demo app. Trying to download the first DASH media -

  • Download the 854 * 380 track - the download speed did improve with increasing the number of threads, but:
    • Using 1 thread: Download finish roughly in 49s. For each segment, the maximum download time is around 1500ms.
    • Using 2 threads: Download finish roughly in 30s.
    • Using 3 threads: Download finish roughly in 17s.
    • Using 67 threads (this media has 67 segments): Download finish roughly in 7s. Notice that for each segment, the maximum download time around 7000ms.

Here you can see that with more threads added, the time for downloading each segment increases as well, due to the "traffic jam".

Also with the same media in a different track:

  • Download the 1920 * 856 track:
    • Using 3 threads: Download finish roughly in 68s. For each segment, the maximum download time is around 8000ms.
    • Using 67 threads: Download finish roughly in 66s. For each segment, the maximum download time is around 66000ms.

There is almost no improvements even if you significantly increase the number of threads. As the segments for this track is much larger, the performance of the multiple threads are more easily to be bottlenecked by the bandwidth. It's hard to say where the optimal number of thread lies in -- I think this needs more experiments.

tianyif avatar Jul 23 '25 19:07 tianyif