Playback stalls forever in buffering with "Music Choice" content tunneling #6366
Comments
|
The issue is caused by the stream, but it points out something worth considering in ExoPlayer's buffering state transitions algorithm... Because the video frame rate is so low the first segment of video is loaded, decoded and buffered in the video MediaCodec, then the renderer is no longer isReady(). Falling out of the loop it would move the playhead forward enough to cause it to need to load more video, however the video never gets a chance to catch up to the audio because the audio renderer is stoped note even a second into playing. Here's the PTS from the first segments: AUDIO VIDEO Because the renderers are stopped when buffering begins, the audio does not play out in tunneling mode, so the current position does not increment. With this condition setup, the player is stuck in buffering mode. Fixing the stream will fix it (I'll verify this and close the bug then), but something worth considering dealing with in the buffering state transition algorithm. |
|
I'm working with the HW vendor on this so stay tuned.. The bottom line is the player is stuck in buffering mode. I believe this is because it has queued a huge number of frames to the video decoder (because the frame rate is so low) then the audio track stops accepting writes. I'll keep you in the loop in this bug, my guess is what we could do is limit then number of un-rendered buffers queued to the video codec. |
|
I believe this issue is similar to #1874, but with very different root cause. The conditions to set this up are:
Condition 4 causes the Condition 3 causes playback time not to advance. Here's logging for a normal buffering enter/exit sequence: And, the failing case, the pause causes the These log lines repeat forever: |
See issue google#6366 for more blow by blow of the issue. The work around is to keep the video renderer ready, even if it is out of upstream samples, as long as it has samples in the codec that will eventually hit their render time. A more "correct fix" might be to understand and implement the logic for AudioTrack.write() when the audio track is paused.
|
I haven't had time to look at this properly yet, but I wonder if this happens because in tunneling mode we never get output buffers from the video codec so the condition here will always be false, which means that the renderer can stop being ready if its source is not ready even if it has a pending output frame to show. Could you clarify "The issue is caused by the stream" -- were you able to resolve this by fixing the stream? |
I thought so, but no... As long as the audio is close the tunneling code syncs it to the video ok. And yes, what you say about tunneling is exactly correct. Because libstagefight is syncing audio and handling all processing of the frames we stall forever unless audio is allowed to play. I closed the old pull request and submitted a more cleaned up fix (pull request #6407) I'm testing it on FireTV now, it works on Amino and Arris STB's, while you look over the change. |
|
This error could occur on any streams, the Music Choice (https://musicchoice.com, I know, this is a US thing... I think Sky offers similar channels for you UK people ;-) ) streams just aggravate it much quicker. I sent you a URL on my personal S3 bucket with a snippet of the channel. |
In tunneled playback mode the video renderer is potentially 'ready' with output at anytime there are buffers queued to the codec. This fix add the more specific boolean `hasOuputReady()` and uses this in the `isReady()` check. This changes fixes issue google#6366 The call to dequeueOutputBuffer() simply returns TRY_AGAIN always in tunneled mode (this comment is correct: google#1688 (comment) so the super.hasOutputReady() is always false in tunneling mode, even though the codec may have output ready.
In tunneled playback mode the video renderer is potentially 'ready' with output at anytime there are buffers queued to the codec. This fix add the more specific boolean `hasOuputReady()` and uses this in the `isReady()` check. This changes fixes issue google#6366 The call to dequeueOutputBuffer() simply returns TRY_AGAIN always in tunneled mode (this comment is correct: google#1688 (comment) so the super.hasOutputReady() is always false in tunneling mode, even though the codec may have output ready.
|
@stevemayhew Sorry for the delay. I've emailed you directly about diagnosing this and getting a test device. Thanks. |
|
@andrewlewis and @ojw28 I've converted the pull request (#6407 ) to draft as I have a new team member working on this issue. We want to simplify the logic to achieve this and make it a bit more bullet-proof (need to make sure it does not block moving from READY to BUFFERING state when needed). The basic idea remains the same, add a Please pass along an address (you can post or email it to me) where we can send you box[es] that reproduce this problem. All the boxes are Broadcom based. |
Content description
The content is a stream generated from Music Choice channels (often found in cable broadcast). What happens is playback stalls in buffering state, the video renderer is stalled (
Renderer.isReady()reports false because the sample queue has been completely read) but no more video segments loads are kicked off (LoadControldoes not request loading).I've only reproduced this on Broadcom STB hardware (Broadcom BCM7271 based) with tunneling on.
Link to test content
Provided by email.
[REQUIRED] Version of ExoPlayer being used
Dev-v2-2.10.4 (sha d1ac272)
[REQUIRED] Device(s) and version(s) of Android being used
Android P on an Evolution eSTREAM STB.
[REQUIRED] A full bug report captured from the device
Provided by email.
The text was updated successfully, but these errors were encountered: