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

HLS stream always starts with the lowest quality #281

Closed
JanKokalj opened this issue Feb 5, 2015 · 8 comments
Closed

HLS stream always starts with the lowest quality #281

JanKokalj opened this issue Feb 5, 2015 · 8 comments

Comments

@JanKokalj
Copy link

Is it possible to prefetch/precache stream or set to the player with what stream should it start to stream. I have a problem that I have an excellent wifi connection but my streams starts with the lowest quality for the first couple of chunks (2seconds long). It would not be a problem if I had a long video, but I working with short videos (max 1minute long).

@andudo
Copy link
Contributor

andudo commented Feb 5, 2015

@JanKokalj, player always starts why the first variant that is listed in the master playlist, and only then it switches to a more appropriate one. This is by HLS spec. If you want your videos to start with a high bitrate, put a high bitrate on the top of your master playlist.

We currently don't have an additional ability to tell the player which bitrate to use or start with.

@ojw28 ojw28 added the question label Feb 9, 2015
@ojw28
Copy link
Contributor

ojw28 commented Feb 9, 2015

If you wanted the add the ability, the place to do it would be in HlsChunkSource. The initial variant to use gets selected at the bottom of the constructor in that class. We'd consider accepting a patch if you can come up with a nice abstraction for this (you're also free to make the modification locally, just for use in your own project). We'll probably add this functionality at some point, if not.

More generally, determining which format to start with is a non-trivial problem, because until you're fetching data, you don't really know what bandwidth you have. You can guess based on the network type, or retain state from previous playbacks or unrelated network requests that your application is making, but in general it's a non-trivial problem, and different developers are likely to have a preference for different approaches. This is why we opted for the simple approach according to the HLS spec, and will continue to do so, but allowing different developers to override this behavior is something that it makes sense to allow.

@nbruning
Copy link

We have a small patch that allows subclasses of HlsChunkSource to implement a custom algorithm for selecting the initial variant.
http://pastebin.com/9GbnG4n2

@DavidMihola
Copy link

Is there any chance that this will still be included in the ExoPlayer project? How about passing an additional InitialVariantSelector to the HlsChunkSource?

@ojw28
Copy link
Contributor

ojw28 commented Jun 19, 2016

In the 2.x.x experimental branch HLS uses FormatEvaluator, just like DASH and SmoothStreaming. By implementing a custom FormatEvaluator it will be possible to change the initially selected format.

@kshivaram
Copy link

kshivaram commented Sep 16, 2016

when we use InitializationTrackSelection in 2.x to select the initial variant to be the highest, it switches back to lower format for a few seconds and then back to good quality thereafter. How do I select the all the initial variants to be of high quality?

@b95505017
Copy link
Contributor

b95505017 commented Sep 20, 2016

How do we change InitializationTrackSelection to another in demo app?
I want to select the middle of the format sorting by bandwidth in the begining instead of the first chunklist in playlist.

It means that we have to call HlsChunkSource#selectTracks right before everything start to load.

@ojw28
Copy link
Contributor

ojw28 commented Jan 30, 2017

Fixing the initial selection is now tracked by #2353. Let's use that issue for tracking. Closing this one.

@ojw28 ojw28 closed this as completed Jan 30, 2017
@google google locked and limited conversation to collaborators Jun 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants