iOS 11 end-of-stream issues

[defagos]

Starting with iOS 11, a few weird issues affect end-of-stream playback:

• Attempting to seek to the end of a some medias fails. The controller never leaves the seeking state.
• For some medias (e.g. 19h30 of the demo project), after playback normally ends, the playback button must be tapped twice to restart playback.

These problems do not occur on iOS 10 or below.

We initially hid these iOS 11 regressions under the rug (most notably failing tests, see 264668a12584cd4d655e20469fdb8e1c5b2bd184), thinking they might be ironed out with iOS 11 minor releases. This is not the case with iOS 11.2, and I think we now must address those issues, as the probability they get fixed in a near future diminishes.

[defagos]

Here is a URL for which these two behaviors can be reproduced: https://rtsvodww-vh.akamaihd.net/i/journ-12h45/2018/journ-12h45_20180220_full_555600-,301k,101k,701k,1201k,2001k,3501k,6001k,.mp4.csmil/master.m3u8?__b__=800.

[defagos]

The first regression has been mitigated in AVPlayerController, which behaves fine. The second regression, on the other hand, also affects the system player controller.

We can probably mitigate the first issue as well. For the second issue, I think we should have a look at the playlists and chunks to discover whether there is an encoding issue somewhere.

[defagos]

According to my tests, it seems seeking near the last chunk of some medias may not work correctly.

More precisely, AVPlayer seek method behavior has changed in iOS 11. Previously, you could provide a time outside the valid media time range, the player would seek to the nearest available location in all cases. With iOS 11, you can still attempt to seek in the vicinity of the media end, but try to seek too far away and it will fail (according to my tests, how far probably depends on the chunk size and therefore on the media itself).

Our seek method implementation assumes that if a seek request is made it will succeed, or fail because another seek request has been made (which will itself succeed). With iOS 11 changes, these assumptions break. We therefore need to make our implementation more resilient against such failures.

Maybe we should also open Apple bug reports (at least for missing documentation, but maybe for regressions).

[defagos]

I applied the following approach:

• Document behavior for start and seek target times outside the valid media range as undefined. These behaviors have changed with iOS 11 and should in general be considered as errors. Client applications are now always responsible of providing correct times and should not rely on the player magically fix the times they provide.
• Remove tests which were disabled on iOS 11, and which tested functionality leading to these undefined behaviors.
• Fix seek issues by ensuring the seek context is always cleared, even if no seek succeeds.

The fact that the play button must be tapped twice to restart playback may be related to stream encoding issues. AVPlayerController exhibits even worse behavior (doesn't restart at all). I recommend we don't do anything for the moment. A related bug report could be opened, but we have to be sure that streams are not broken for some reason.

[defagos]

The second issue seems related to an iOS 11 regression. When a media has ended and a play is attempted, our implementation performs a seek. This first seek is not reliable depending on the media, or if no network is available.

[defagos]

Playback unreliable restart (depending on the media, it seems) are still occurring with iOS 12 beta 2.