DASH/HLS/SS downloads: Parallelize & merge requests to improve download speed

[ojw28]

ExoPlayer currently requests segments one at a time when downloading segmented media. This means that the network is not fully utilized, particularly in cases where there's significant latency between client and server. There are two approaches for improving this:

1. Parallelize segment downloads so that the network can remain more fully utilized.
2. Where consecutive segments have the same URL and consecutive byte ranges (normally true for DASH VOD, and also supported in HLS with #EXT-X-BYTERANGE), it's possible to request multiple segments in a single HTTP request.

In both cases, any implementation should ensure that demuxed tracks are downloaded at approximately equal rates, because users expect that if something is ~33% downloaded, approximately the first ~33% of that piece of content will be playable.

What is the progress of this issue. the performance of our product offline download feature is extremely poor. because of the low ts cdn, we need parallelize segment downloads to download more ts files in parallel.

[Stijak]

This is really serious issue. For a bare 600MB (in 8000 chunks) player needs about 40 minutes to download (over 300 MBIT network)...
This is only 15%ish percent faster than action-file based implementation, and more then 10 times slower then our old custom download implementation on same medias...

[janeriksamsonsen]

@Stijak - just measured a download on my side:
Pixel 3 XL
100mbit connection
Around 8700 segments (video + audio + subtitle) where each segment is 2 seconds long.
Total downloaded: 4.2GB
Time to finish: 11 minutes

Your numbers sounds strange. Can you please share some details about your device and implementation?

I do however also see the need for parallelized downloads since ExoPlayer download is still quite a bit slower than our 3rdparty player/downloader.

[Stijak]

Ok, thanks for feedback. Judging on your responses, on my test Galaxy S9+ speed should be high even on exoplayer 2.9, and yet, still slow, and there are no CPU bottlenecks or anything like that.

I even transferred DASH from CDN to my local macbook apache to eliminate eventual CDN problems with small chunks.
Ok, I guess I will keep looking and the problem is not in exoplayer, although I don't understand how my code could influence download speed.

[Stijak]

It seems that significant portion is spent on request initialization...
And much smaller audio files are sometimes slower...

If results from both mobile network (to CDN) and another team in another part of the globe wasn't similar, I would blame local WiFi...

[Stijak]

Update:
I repeated the same tests (local apache server) with dash samples from https://dash.itec.aau.at/dash-dataset/

I used red bull sample, since it was longest, and using same bitrate we aim for our content, and our production app for testing (so it would be apple to apple comparison), I was able to test 15 second segment size and 1 second segment size downloads.

15 second segments download finished in less than 2 minutes, while 1 second segment took about 8 minutes. So here clear differences in download speed.

1 second is about 5 000 segments and still noticeably faster than our comparable content. Is it some other encoding option, or DRM (our content is using Widewine) I am not sure, but will try to reach solution with content providers...

[zourb]

Are there any updates for this issue? The parallelized downloads feature is really important especially for poor segments downloads' speed.

[noamtamim]

@ojw28 is this something you're currently working on? We're looking to move from our current download solution to ExoPlayer's built-in, and this is a serious blocker.

[tonihei]

Unfortunately no progress yet. But acknowledged the renewed interest and we should probably take a look soon.