defagos
commented
9 months ago I finally could understand why sometimes we observed Picture in Picture being paused during restoration, not from the PiP overlay itself, but by starting playback of another content. This investigation and the related fix were made as part of #702.
When do pauses occur?
Pauses occur when transitioning via PiP from some content A, played with a player supporting PiP, to some content B, played in the same player but not supporting PiP.
Compare:
-
Content A played with a player supporting PiP, transitioning via PiP to content B in the same player supporting PiP:
https://github.com/SRGSSR/pillarbox-apple/assets/170201/eea74446-2275-45ff-8ac2-69c5361d674f
-
Content A played with a player supporting PiP, transitioning via PiP to content B in the same player not supporting PiP:
https://github.com/SRGSSR/pillarbox-apple/assets/170201/64de7277-f7c6-4b8c-8070-0febd4693d93
In the first case playback continues, while in the second one playback is paused.
Remark
You might think that this case is convoluted but actually it isn't. The fact that a view supports PiP not only supposes that the video view has been configured appropriately, but also that the view itself is installed in the hierarchy and therefore could register itself with a Picture in Picture controller.
Depending on how a player user interface is implemented the view might not be immediately available, e.g. if the implementation only displays the video view once the media type is known (see #696 for a related issue that needed to be fixed as well). This is perfectly legitimate and can happen in practice. We have no way of preventing such implementations and we cannot have behaviors break just because of subtle layout implementation refactorings that are part of any development process.
Why do pauses occur when transitioning to a layout not-supporting PiP?
Our implementation explicitly stops Picture in Picture using the dedicated API when a video view appears for the first time (via onAppear(perform:)). To better understand what happens let us have a look at what we have if we remove the stop and let PiP playback continue in the overlay. We then simulate the stop by tapping the restoration button in the PiP overlay:
-
Content A played with a player supporting PiP, transitioning via PiP to content B in the same player supporting PiP:
https://github.com/SRGSSR/pillarbox-apple/assets/170201/8c203cfe-2afc-4f84-8cb5-e75ae8bef5f6
-
Content A played with a player supporting PiP, transitioning via PiP to content B in the same player not supporting PiP:
https://github.com/SRGSSR/pillarbox-apple/assets/170201/8bff9237-8984-4306-8a22-402452357ab6
We can easily understand what happens now:
- In the first case the layer is the same in the PiP overlay as in the full screen player. When stopping PiP the layer is merged back without interruption.
- In the second case the layers in the PiP overlay and in the full screen player are different, yet the
AVPlayeris the same (thus the content appearing twice). When stopping PiP the player is paused, which makes the other layer as well.
How can we fix this issue?
To fix the issue visible in the second scenario we need to detach the player from the PiP layer before PiP is stopped, but only when the view we are transitioning to does not support PiP anymore. This way we avoid the player being shared and pausing playback in the other layer when PiP is closed:
https://github.com/SRGSSR/pillarbox-apple/assets/170201/217ca526-5965-4312-846e-09562e91b408
The programmatic PiP stop is not even needed in this case since this change forces PiP to close automatically. The stop is still needed for the first scenario, though, so that the PiP overlay is properly returned when transitioning to the same view supporting PiP.
As a developer integrating Pillarbox I want to be able to implement PiP deeper in my application, so that users can browse the application while continuing playback using PiP.
As a Pillarbox user I want to be able to use the app while watching content.
Acceptance criteria
Hints
Tasks