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

Retain played media in buffer unless space is actually needed to buffer further ahead #896

Open
ddobrev opened this issue Oct 24, 2015 · 11 comments
Assignees

Comments

@ddobrev
Copy link

ddobrev commented Oct 24, 2015

When playing audio without true streaming, the whole audio has loaded and it's then sought to before the current progress (that is, the track is at 0:45 and the user seeks to 0:20), ExoPlayer buffs again as indicated by getBufferedPercentage.

@ojw28
Copy link
Contributor

ojw28 commented Oct 25, 2015

This is currently working as intended, in that the player is designed to always discard buffer behind the playback position in order to buffer further into the future.

However, this doesn't make sense in the case that the whole piece of media can be buffered, or where the buffer isn't full yet. We should only discard when we actually need to reclaim memory to buffer further ahead. Marking as an enhancement to track delivering this improvement.

@ojw28 ojw28 changed the title ExoPlayer rebuffs after seeking Retain played media in buffer unless space is actually needed to buffer further ahead Oct 25, 2015
@ddobrev
Copy link
Author

ddobrev commented Oct 25, 2015

Thank you for taking action. Would you have any idea when this will be fixed?

@ddobrev
Copy link
Author

ddobrev commented Oct 26, 2015

I would like to help fix this bug. As a start, is the problem caused by audioTrack.reset(); in MediaCodecAudioTrackRenderer.seekToInternal? Any idea what the body of that latter method should be changed to?

@ojw28
Copy link
Contributor

ojw28 commented Oct 26, 2015

Some major architectural changes will probably be required to deliver this (it's not a bug as such - more just a limitation with the existing design that we need to remove). It really needs fixing as part of a larger design overhaul, since we have multiple such limitations and they should be considered together as opposed to in isolation.

@ddobrev
Copy link
Author

ddobrev commented Oct 26, 2015

I understand, in other words, it's not going to happen within the next month, is that correct?

@ojw28
Copy link
Contributor

ojw28 commented Oct 26, 2015

Correct. Sorry! We'll get there eventually though.

@ddobrev
Copy link
Author

ddobrev commented Oct 26, 2015

I understand. Thank you for the information and for taking this issue into account.

@ddobrev
Copy link
Author

ddobrev commented Jan 22, 2016

@ojw28 hello, has there been any progress on this issue or on the design overhaul you mentioned?

@ojw28
Copy link
Contributor

ojw28 commented Jan 22, 2016

This issue is not a priority for us, and there is no ETA. We're working on a bigger re-design, but this isn't considered a priority even for the first stage of that effort. Sorry.

@ddobrev
Copy link
Author

ddobrev commented Apr 20, 2016

Hello, could you please provide an update about this issue or about the re-design?

@natez0r
Copy link
Contributor

natez0r commented Nov 30, 2017

I see this causing exoplayer to redownload mp4s when we use repeat modes. They are only 5 seconds long, but it causes a lot of wasted data. I know we could use a cache data source, but it seems like a heavy approach.

@ojw28 ojw28 assigned tonihei and unassigned ojw28 Jul 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants