FrameworkSampleSource fails to stop buffering and start playback

[IanDBird]

I'm having issues when i'm trying to play an MP4 but at a non-zero offset. I'm allowing the user to "Resume" their video where they last stopped playing, but occasionally (maybe 1 in 3), ExoPlayer refuses to start playback.

I don't think I am doing anything unusual when configuring the player, e.g.

    m_player.prepare(renderers);
    m_player.seekTo(m_offset);

I can see from logging in the onPlayerStateChanged callback, that the video player goes through the following states: STATE_IDLE, STATE_PREPARING and STATE_BUFFERING. It then remains in the buffering state indefinitely.

The issue appears to be effected by the fact i'm trying to seek in the video. I'm yet to have it fail when starting the video at the beginning. Is this a known issue? Are there any workarounds to ensure that playback always begins?

[natez0r]

I am also seeing this problem. For me it's easiest to reproduce if you seek near the end of the video and seek back to the beginning. We only use progressive download mp4 files.

Still happening in 1.0.13.

[IanDBird]

I retested the other day against the latest dev branch and was still able to reproduce. I explored different options how to try and workaround it myself, but since the issue is the player remaining in buffering, it's very difficult to determine the difference between a video buffering for a long time vs this issue. If the video is just taking a long time to load, the last thing you want to do is kill the video and try to load it again...

[ephemient]

I think I can get it to happen more frequently by seeking right to almost the end of the file.

With additional logging in ExoPlayerImplInternal.rendererReadyOrEnded, it seems that MediaExtractor.getCachedDuration sometimes stops short of the requested buffer duration. Since FrameworkSampleSource.continueBuffering is a no-op, there is no way to ask it to buffer more, and ExoPlayer remains in this state indefinitely.

[ojw28]

That sounds plausible. The easiest way to work around the issue would be to make an instance like:

ExoPlayer.Factory.newInstance(numRenderers, 0, 0)

Is your use case playing back regular MP4 files? The complete ExoPlayer based solution to this problem would be to implement everything at the application layer and stop using FrameworkSampleSource. This would give us enough control to fix these problems properly, as we've done for DASH and SmoothStreaming. It's quite a lot of work though.

[ephemient]

Yes, I'm playing MP4s from a URL. Setting the buffer times to 0 does seem to avoid getting stuck, but doesn't feel great for other reasons.

As another potential workaround, how acceptable would it be to implement a buffer within FrameworkSampleSource which continues to read samples ahead from MediaExtractor until it has cached enough? Although I'm not sure how to tell if we're in the buffering or rebuffering case from there.

[ojw28]

That doesn't sound ideal either. As per above, the best option by far is to implement everything at the application layer.

Maybe the best workaround would be to have FrameworkSampleSource.getBufferedPositionUs claim that it's buffered to the end if you're within the last ~5 seconds or so of the content. That would be more or less equivalent to setting the buffer times to 0 selectively, only when seeking near the end of the content.

[ojw28]

On the latest dev branch, you can use ExoPlayer's application level MP4 extractor to avoid this issue (in the demo app, use TYPE_MP4 rather than TYPE_OTHER).