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

Slow HLS stream download #4828

Closed
semirzahirovic opened this issue Sep 17, 2018 · 6 comments
Closed

Slow HLS stream download #4828

semirzahirovic opened this issue Sep 17, 2018 · 6 comments
Assignees
Labels

Comments

@semirzahirovic
Copy link

semirzahirovic commented Sep 17, 2018

Issue description

We have tested the downloading of HLS streams in our app. Although it works fine, time to download stream is huge. Is there an easy way to reduce download time?

On the server-side, everything is hosted on a Google Storage Bucket, served through Google Cloud CDN using HTTP/2 so the hosting should not be the bottleneck.
When doing a quick benchmark on desktop, the first download (before being cached by the CDN) takes 11 minutes, while the second one (after being cached at the nearest edge-location) takes only 3 minutes.
However, when downloading the same file in our app using ExoPlayer, the download takes 22 minutes on the first try and 18 minutes after caching.

We have also tried creating bigger segments and in that case download is much faster, but problem is that seeking when streaming takes more time, so that solution is not optimal at all.

We are also using OkHttpDataSourceFactory with v3.11.0 of OkHttp.

Link to test content

Here is the link where the issue can be reproduced: https://storage.googleapis.com/strillo-demo/hls-test/oldfashioned_girl_1808_librivox.m3u8.

Version of ExoPlayer being used

Exo player v2.8.3.

Device(s) and version(s) of Android being used

Any supported device/version.

@andrewlewis
Copy link
Collaborator

#4253 may be related.

@semirzahirovic
Copy link
Author

@andrewlewis thanks for suggestion. Not sure if it correlates to the issue you linked as this is reproducible by having the Cache folder empty and downloading only one stream.

@andrewlewis
Copy link
Collaborator

I wonder whether the mobile device is relatively slow because the chunk downloads are serialized. #4273 is a feature requests for parallel chunk downloads. I guess one way to investigate this hypothesis would be to start multiple downloads concurrently and look at the total throughput.

@ojw28
Copy link
Contributor

ojw28 commented Sep 17, 2018

  • Can you be more specific about what device(s) you've tested this on?
  • Are you writing to internal storage or an SD card, and does this make any difference? If the latter, have you tried with a different SD card? If I remember correctly, we've seen some other cases where it's turned out that the SD card is just incredibly slow to write to, so it would be helpful if you could check this.

If it's not the SD card then I agree it's probably a dupe of #4273.

@semirzahirovic
Copy link
Author

semirzahirovic commented Sep 18, 2018

@ojw28 Yeah, it is a dupe of #4273. We tried downloading in internal storage and SD card. Since there is a lot of segments, the download is slow. Tested on S7, S9, S9 plus, Pixel 2...

We are hoping that the parallel segment download feature will be implemented soon.

@ojw28
Copy link
Contributor

ojw28 commented Sep 18, 2018

Closing as duplicate.

@ojw28 ojw28 closed this as completed Sep 18, 2018
@google google locked and limited conversation to collaborators Jan 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants