srgmediaplayer-apple
srgmediaplayer-apple copied to clipboard
SRGSSR
Improve performance in scrollable views
When using in a scrollable view (table, collection), media starts lead to hiccups on some devices. Several strategies could be investigated to improve the situation:
- Improve asynchronous
AVPlayerresource loading, maybe use a customAVAssetResourceLoader - Use AsyncDisplayKit
- Hack something else
We discovered another AVPlayer related performance issue. When using interactive view controller transitions, it sometimes happen that sometimes a view controller dismissed with a custom animation cannot be dismissed anymore. This often happens when the user still interacts with the animated controller when presented and dismissed in a row, and when (and only when) this view controller somehow instantiates an AVPlayer or related item. If such code is removed, the transition works just fine. The custom transition code is therefore not to blame.
There is probably an iOS issue with how interactive transitions have been implemented by Apple, especially when some main thread works is performed while a transition is running. We probably have to improve our implementation so that as much main thread works is performed in the background.
If we comment out -setPlayer: and call -play on the player when assigned to the player property, the issues does not arise anymore. There is probably something going on in -setPlayer: and related KVO / notification callback leading to the issue.
It seems the more AVPlayer work we remove during interactive transitions, the better it works (e.g. it works a lot better if only preparing for playback without calling -play afterwards). This seems to work better but still does not work correctly all the time.
Apparently, the problem with interactive transitions is due to the fact that a gesture recognizer can be triggered right at the end of an animation, after having been detected while the animation was running. This mostly occurs when the user heavily interacts during the animation.
If the animation is a presentation animation and the gesture leads to dismissal, then recognition will be triggered right at the end of the presentation animation, starting dismissal too early, and putting view controllers in a seemingly incorrect state. As a result, the view controller cannot be dismissed anymore.
It seems having an AVPlayer increases the probability such detections might occur (probably because the player does some main thread work). It appears the player itself is not the issue.
Wrapping the implementation of such a gesture recognizer in a dispatch_async block executed on the main thread is very interesting and might help in understanding why view controller transitions can be quite tricky to get right.
It seems that view controller animations trigger -viewDidAppear: just before finishing. At this point, the gesture recognizer will detect touches (even if the recognizer has been added in -viewDidAppear:!). If an event is received by this gesture recognizer, leading to the interactive dismissal transition being triggered, then the issue arises.
The -viewDidAppear: method is called when -completeTransition is called on the context. Further investigation is needed, but I think that the call to -viewDidAppear: is probably not the last thing -completeTransition does, which means the transition is probably not complete from an internal point of view when -viewDidAppear: is called.
I discovered that heavily interacting with the view (even if displayed once normally) will trigger the gesture recognizer so fast that -dismissViewController gets called too fast several times in a row, leading to the issue.
The modal interactive transition issue was related to its implementation, leading to race conditions on heavy view controllers bearing an AVPlayer. These issues have been fixed in commit 6cb5c89eae106149724b1f90ed73abd304413271.
Controller performance improvements have been attempted along the way (most notably by loading assets asynchronously), but those could lead to subtle race conditions as well, with no noticeable improvement in media lists, and some issues with other unit tests we have. These changes have therefore been reverted but can still be seen in the history for reference (commit 9e1fdcfc6ca0ccf22432defab5511e88bf6441a3).
We discovered a semaphore issue with AVAsset track property access while preparing to play, freezing the app for some time. This will be fixed in version 2.0.4.
To improve startup time, we could probably apply advice from the WWDC 2018 HLS session: https://developer.apple.com/videos/play/wwdc2018/502/.
Very interesting information about async loading of asset properties is discussed in https://developer.apple.com/videos/play/wwdc2014/503/.
Unsafe asset access will been fixed in SRG Media Player 2.6, which removes many hiccups which could still be encountered.
I don't want to close this issue for the moment, though. We should namely:
- [ ] Create a table view of medias and see whether hiccups are still noticeable.
- [ ] Check whether other improvements can be made.
View performance improvements associated with AirPlay button layout have been delivered in version 2.7.
Player initialization could be improved. As announced during WWDC 2019, though, iOS 13 should make some significant improvements in this area. We should wait.
SRG Media Player successor found in the Player package of our Pillarbox library improves performance and eliminates most issues related to improper property observation which was made in SRGMediaPlayerController. Closed.