tonihei 25e31743d3 Don't require the existence of the next period to wait for its stream. ... We have a workaround for uneven sample stream durarions in playlists that assumes a renderer allows playback if it's reading ahead or waiting for the next stream. 652c2f9c18 changed this logic to no longer require to wait until the next stream is prepared due to a change in how we advance media periods in the queue. However, the code falsely still requires the next stream to exist (even if it's not prepared). This can cause a stuck buffering state when the difference in the duration of the streams is more than what we buffer ahead because we never create the next stream in such a case. Note: DefaultMediaClock.shouldUseStandaloneClock has roughly the same logic and also doesn't require the next stream to be present. Also fix a test that seemed to rely on this stuck buffering case to test stuck buffering detection. Changed the test to not read the end of stream to ensure it runs into the desired stuck buffering case. Issue:#7943 PiperOrigin-RevId: 333050285		2020-09-25 16:30:25 +01:00
..
androidTest	Separate the dump files from the test assets	2020-08-17 16:13:53 +01:00
main	Don't require the existence of the next period to wait for its stream.	2020-09-25 16:30:25 +01:00
test	Don't require the existence of the next period to wait for its stream.	2020-09-25 16:30:25 +01:00