Stream request results in multiple requests #1041
Labels
Comments
|
Yes, this is a known sub-optimality related to how stream selection works in |
|
Thanks for the quick response, can we expect this behaviour for all tracks (MP3, AAC etc) or just some? |
|
I believe this currently happens for all container media types. It does not occur for DASH or SmoothStreaming playbacks. |
|
Will you have the plan to fix this issue? |
|
We're currently working on a 2.0 version of ExoPlayer, in which this issue will be fixed. We do not have an ETA as of now. |
ojw28
added a commit
that referenced
this issue
Jun 15, 2016
…s" state. 1. SampleSource now has an explicit track selection state. This state is entered after the source is prepared, and also by calling startTrackSelection. 2. endTrackSelection commits selection changes, and is responsible for doing the right thing w.r.t starting/stopping/restarting load operations. 3. All sources now start or restart a load in the case of a new track selection. This fixes a problem where a source could be advanced by repeatedly disabling and re-enabling whilst paused. Some sources didn't restart a load in this case, since the position was unchanged, however the downstream renderer would then consume media up to the first keyframe in order to render something. Hence each disable/re-enable would advance by a keyframe. 4. This change will enable a subsequent change where we'll discard media for non-selected tracks earlier than we do currently (i.e. we'll hook the extractor to a dummy track output, so the samples will never be written to a rolling buffer). This will enable a further subsequent change where buffer contributions are per-renderer rather than per-source. Issue: #1041 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=118024436
|
This is fixed in the 2.x.x experimental branch. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
When the ExoPlayer is used to play certain audio files by streaming them from the network, the ExoPlayer makes 2 attempts to retrieve the file at varying byte offsets before commencing playback.
Steps to reproduce the problem from the demo application:
Details
One execution of the example above, connected over wifi on a Nexus 6P, produced the following network requests:
GET /exoplayer-test-media-0/play.mp3 HTTP/1.1
User-Agent ExoPlayerDemo/1.5.2 (Linux;Android 6.0.1) ExoPlayerLib/1.5.2
Accept-Encoding identity
Host storage.googleapis.com
Connection Keep-Alive
GET /exoplayer-test-media-0/play.mp3 HTTP/1.1
Range bytes=313-
User-Agent ExoPlayerDemo/1.5.2 (Linux;Android 6.0.1) ExoPlayerLib/1.5.2
Accept-Encoding identity
Host storage.googleapis.com
Connection Keep-Alive
Expected behaviour
Only a single network request is made by the ExoPlayer.
Notes
We encounter this problem with AAC/MP4 files as well.
When we test this file (/exoplayer-test-media-0/play.mp3) with the Android MediaPlayer, it loads in one request.
GET /exoplayer-test-media-0/play.mp3 HTTP/1.1
User-Agent stagefright/1.2 (Linux;Android 5.0.2)
Host storage.googleapis.com
Connection Keep-Alive
Accept-Encoding gzip
The text was updated successfully, but these errors were encountered: