Streaming mp4 with byte ranges fails to restart after rebuffering.

[johngray1965]

The Demo app runs into an issue in streaming an mp4 from a very simple server that feeds the whole file or gives you a range (A watered down html5 video protocol). It works as long as app doesn't go into rebuffering. If it does go into refebuffering, it'll build the buffer back up, but never goes back to ready.

You can test this by adding the following sample to top of MISC in Samples.java
      new Sample("Broken", "http://test.agora-net.com", Util.TYPE_OTHER),

I'm happy to supply the mp4 or the simple script I use to send it back, I'm a little leary of leaving the video on my server for very long though.

I see where this problem was been reported in the past (twice I believe), and the solution was to change the type to TYPE_MP4, but that doesn't appear to exist any longer.

I realize this is a somewhat primitive way to stream the video, but I don't control that end of it.

The video in the test is an UHD video taken with my phone. It has very high bandwidth requirements. Which demonstrates the problem well (unless you can manage to really pull down the data fast enough to not run dry).

Thanks

[ojw28]

Maybe the bandwidth requirement is so high that it's not possible to buffer the minimum amount of media for playback to resume. Try using ExoPlayer.newInstance(rendererCount, 0, 0) to create your ExoPlayer instance. Does that allow playback to resume (albeit in a choppy fashion)? You can also try bumping up BUFFER_SEGMENT_COUNT in ExtractorRendererBuilder in the demo app.

If neither of those help, I would suspect that your server does not properly implement range requests.

[johngray1965]

ExoPlayer.newInstance(rendererCount, 0, 0) does indeed allow it to resume in a choppy fashion.

When it doesn't resume (with the defaults of 1000 & 5000), it seems like it rebuffers but doesn't quite get to returning to ready. Seems to build the buffer reasonably well and then stops. I assumed it filled the buffers. Setting buffer and rebuffer to 1000 & 1500, and doubling BUFFER_SEGMENT_COUNT, I'm playing it well at moment, but I think I'm getting lucky (It never runs dry).

[ojw28]

Closing, since it seems like the answer is to either lower the bitrate of the content, increase the buffer size or decrease the minimum buffer duration. Providing a better (i.e. more obvious) failure mode when the buffer is too small is tracked by #583.