Looping and concatenation with uneven track end times can cause stuck buffering state. #1874
Comments
|
I ran into (maybe) this bug myself today with this video: http://vid.pr0gramm.com/2017/01/21/8da9138fe27c1b97.mp4 ffmpeg tells me, that the audio ends at 19.45s, video already at 18.92. With the end of the video stream, exo player freezes and wont play the last half second of audio content. I could track it down to a blocking call in |
|
Well I tried the workaround @ojw28 mentioned in #1846 , it does not help though. When the player is about to reach the end, |
|
@zijing07 - There was some confusing posting of similar-but-unrelated issues onto the bottom of some of the issues that reference this one, which I've now removed for clarify. As an aside, the reason we've started automatically locking old issues is to help prevent this kind of confusion. If you have the issue being tracked here, where the end times of the audio and video tracks are uneven in the media being played, then you need to follow this issue and wait for a fix. |
tonihei
changed the title
|
Just checked several examples; on most of the media, audio and video durations do no match exactly. As a result, most of the videos loop nice for a long time, but some of those hit this issue. |
|
same problem, i just replace setRepleatMode use seekTo(0) when buffer end. |
This avoids spurious position reports following an underrun. Github: #1874 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=170344399
* Always assume a renderer is ready if it's read to the end of its current stream and there's a subsequent period already prepared. This prevents getting stuck when a non-clock renderer has a short stream. * Switch to the standalone clock if the renderer providing the media clock has read to the end of its current stream, is no longer ready, and there's a subsequent period already prepared. This prevents getting stuck when a clock renderer has a short stream. * Remove unnecessary clock synchronization logic (since it would need to be made more complicated as a result of this change). * Don't update the playing period holder when playWhenReady is false. This avoids the position jumping to the start of the next period when seeking to the very end of the current period whilst paused (we still end up showing the first frame of video from the next period, but fixing that will have to wait). Github: #1874 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=170717481
|
This should now be fixed in |
|
one problematical video I have is playing nice on |
|
Hi, any idea when you plan to release this fix? Thanks. |
|
It's fixed in |
|
Cool thanks! |
|
Wow! That's really good news! Thanks very much! |
As per title, playback of a playlist can get stuck in the buffering state if the end times of the tracks of the sample coming to an end are uneven.
The text was updated successfully, but these errors were encountered: