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

Change video track (Quality) on HLS stream #676

Closed
endlessmind opened this issue Jul 31, 2015 · 23 comments
Closed

Change video track (Quality) on HLS stream #676

endlessmind opened this issue Jul 31, 2015 · 23 comments

Comments

@endlessmind
Copy link

When playing HLS streams (like twitch live streams), the player will adopt the the best possible quality, as expected. But I would like to be able to let the users select from available qualities, like in the YouTube app. (If the users don't need the best possible quality and/or have a limited data plans)

But I can't find any way to actually set the video quality manually.
How does the YouTube app accomplice this?

Will the "Steps toward full multi-track support."-commit to the dev-branch be of any use for this kind of functionality?

@ojw28
Copy link
Contributor

ojw28 commented Jul 31, 2015

Full multi-track support should make this easier, because once we have that it should be relatively easy to have the video renderer advertise multiple tracks, like: AUTO,1080,720,480 (or whatever).

YouTube use DASH, where track selection is supported (albeit not in a particularly easy way) using MultiTrackChunkSource. SmoothStreaming playbacks can also make use of MultiTrackChunkSource. Once we have proper multi-track support this class will probably go away.

@crossle
Copy link

crossle commented Jul 31, 2015

+1

@b95505017
Copy link
Contributor

Currently I post a message into HlsChunkSource and change two things:

adaptiveMode = ADAPTIVE_MODE.NONE;
selectedVariantIndex = index;

@endlessmind
Copy link
Author

Can you provide more details on this?
Also, where do you pull the variant-list from?

@b95505017
Copy link
Contributor

Any development news or plans for this issue?

@Unlimity
Copy link

Looking forward to this feature.

ojw28 added a commit that referenced this issue Jan 14, 2016
This is equivalent to DashTrackSelector and SmoothStreamingTrackSelector.
This is a step toward allowing HlsChunkSource to expose multiple tracks,
which is a requirement for supporting WebVtt.

This change also enables WebVtt extractor instantiation.

Issue: #151
Issue: #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111698833
ojw28 added a commit that referenced this issue Jan 14, 2016
There are multiple issues with HlsSampleSource's use of
LoadControl that become apparent when you attempt to use
the same LoadControl for loads by another source.

* In the "limbo" state HlsSampleSource doesn't start any
  new loads, but doesn't update the LoadControl to tell
  it that it doesn't want to load anything either. This
  can prevent another source from starting the loads that
  it needs to make to complete preparation, causing
  playback to become stuck.
* The LoadControl isn't updated properly when the EOS is
  reached. This can cause playback to become stuck near
  the end of the media.
* If HlsSampleSource is released from being in the "limbo"
  state, it doesn't unregister itself with the control.

Issue: #151
Issue: #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111942009
ojw28 added a commit that referenced this issue Jan 14, 2016
Issue: #151
Issue: #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111945466
ojw28 added a commit that referenced this issue Jan 14, 2016
See the documentation of buildTracks for the gory details.

Issue: #151
Issue: #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112149293
@ojw28
Copy link
Contributor

ojw28 commented Jan 14, 2016

It's now possible to select between the available variants in ExoPlayer. The demo app will also list the available variants and allows selection between them (during playback tap the screen and press the "Video" button to see the available variants, or the "Audio" button if your playing audio only).

@ojw28 ojw28 closed this as completed Jan 14, 2016
@ojw28
Copy link
Contributor

ojw28 commented Jan 14, 2016

Note that this is on the dev branch (and will make it into the next release).

@b95505017
Copy link
Contributor

Can't wait to try all of them! Thanks!

@crossle
Copy link

crossle commented Jan 15, 2016

How to seamless switch? @ojw28

@ojw28
Copy link
Contributor

ojw28 commented Jan 15, 2016

We support adaptive mode where we'll seamlessly switch based on the available bandwidth, and we now also support manual selection. We do not support seamless manual selection.

@b95505017
Copy link
Contributor

I tried the demo with some live playlist, and have several ideas:

  1. Sometimes player stuck at buffering after setSelectedTrack for a long time, not sure it's network or player issue.
  2. It would be nice without re-buffering if switch to auto or switching from same MediaFormat in auto to new track.
  3. Could we set a flag to force switching to lower quality if current bandwidth is too bad to serve the manual selection.

@ojw28 ojw28 reopened this Jan 18, 2016
@ojw28
Copy link
Contributor

ojw28 commented Jan 18, 2016

Thanks for your observations.

  • I see the first issue, and we'll take a look and fix that.
  • We don't have current plans to support the second It's pretty non-trivial. Consider the case where the player has buffered a large amount of some manually selected low quality stream. If auto is then selected, it may take so long to switch up that the selection appears to have not done anything. To mitigate that you can proactively throw away some of the buffer containing the low quality stream, but then things start getting complicated from an implementation perspective. It's also debatable how useful the feature would be. If someone has switched from auto to a manual selection then presumably they did so because auto wasn't working well for them. So presumably switching back to auto again is something few people would choose to do.
  • We have a longer term plan to do something that achieves more or less the same thing as in your third bullet point. Basically, we'll at some point allow selection of a subset of streams that should be considered in auto mode.

ojw28 added a commit that referenced this issue Jan 18, 2016
This makes sense until we need to support seeking in the live window.

Issue: #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112402026
@ojw28
Copy link
Contributor

ojw28 commented Jan 22, 2016

There's a separate issue tracking switching in Live (#1174), so let's use that for tracking.

@ojw28 ojw28 closed this as completed Jan 22, 2016
ojw28 added a commit that referenced this issue Jan 22, 2016
When a seek is performed, renderers currently perform the
actions that they need to take in two places: Some changes
are performed in seekTo implementations. Other changes are
performed when discontinuities are read from the source.

In HLS we need to perform what is effectively a seek
originating in the source. To support this, this CL allows
discontinuities read from the source to modify the playback
position. All actions that renderers perform as a result
of a seek are moved to be performed when a discontinuity is
received.

Best way to understand CL:
- Look at SampleSource interface change and then at the
  concrete implementations, to make sure they've been
  changed properly.
- Look at SampleSourceTrackRenderer change.
- Look at concrete renderers. The general pattern is that
  code previously performed in seekTo and READ_DISCONTINUITY
  is merged into onDiscontinuity().

Note: This will be further untangled in V2.

Issue #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112720746
@littlebob
Copy link

Hello @ojw28
I see that seamless manual selection is not supported now.
any plan to have this feature?
If not, any idea for how one can implement this and creates a pull request? Thanks

@ojw28
Copy link
Contributor

ojw28 commented Apr 8, 2016

No immediate plans, no.

@ojw28
Copy link
Contributor

ojw28 commented Apr 8, 2016

In ExoPlayer V2, when it's done, HLS will use a FormatEvaluator to adapt between the variants during playback, as is already the case for DASH and SmoothStreaming. At that point you'll be able to implement this functionality using a custom FormatEvaluator implementation. For now in V1, you'd need to look at modifying HlsChunkSource.

@natez0r
Copy link
Contributor

natez0r commented Jul 11, 2016

@ojw28 any idea when we can expect to be able to use FormatEvaluator for HLS? Is there a timetable for V2?

@toanvc
Copy link

toanvc commented Feb 16, 2017

@ojw28 : is there any ways in v2 to implement this on HLS? I didn't see FormatEvaluator anymore.

@ojw28
Copy link
Contributor

ojw28 commented Feb 17, 2017

All track selection is converged into TrackSelector and TrackSelection in V2, and works in the same way for DASH, SmoothStreaming and HLS. The demo app allows you to select from the available streams in all cases. I suggest you take a look at the trackselection package if you're interested in the internal details.

@toanvc
Copy link

toanvc commented Feb 17, 2017

@ojw28 : Thanks for response! I saw AdaptiveVideoTrackSelection and I did it successfully.
I have questions: when I used

DEFAULT_MAX_INITIAL_BITRATE = 800000;

in my setting as the same value in AdaptiveVideoTrackSelection, but it seems always choose the low bitrate from my stream (my stream support the lowest is 2000000 and the highest is 4000000).
After I changed that value to

DEFAULT_MAX_INITIAL_BITRATE = Integer.MAX_VALUE;

my player run with adaptive bitrate and played with highest bitrate in fast internet connection.
The question is, can I use Integer.MAX_VALUE for my default maxInitialBitrate setting? And what's maxInitialBitrate exactly does? I'm confused with its' meaning in the comment codes

The maximum bitrate in bits per second that should be assumed when a bandwidth estimate is unavailable.

Thanks!

@ojw28
Copy link
Contributor

ojw28 commented Feb 17, 2017

You're doing the right thing. There's a known issue specifically for HLS where the initial selection isn't being applied correctly. This is tracked by #2353.

@toanvc
Copy link

toanvc commented Feb 17, 2017

@ojw28 Thank you so much! You guys are doing great ExoPlayer.
Look forward for the next version with fixing that bug.

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

8 participants