-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Comments
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. |
Thank you for taking action. Would you have any idea when this will be fixed? |
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? |
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. |
I understand, in other words, it's not going to happen within the next month, is that correct? |
Correct. Sorry! We'll get there eventually though. |
I understand. Thank you for the information and for taking this issue into account. |
@ojw28 hello, has there been any progress on this issue or on the design overhaul you mentioned? |
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. |
Hello, could you please provide an update about this issue or about the re-design? |
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. |
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.
The text was updated successfully, but these errors were encountered: