Issue with video layer display when Picture in Picture is enabled for several views at the same time

[defagos]

As an SRF app developer I want to be able to use Picture in Picture with my live center experience, where the player transitions from a non-covering modal to full-screen display, from both player layouts.

Currently the video layer disappears when returning from the full-screen layout when I enable PiP support at the code level. This should not happen.

Context: Pillarbox 2.0.0, iOS 17.

Acceptance criteria

• The following issue is fixed:
  • Opening a live center content from the Resultate tab (might have a replay available from the Gestern tab.
  • Start playback, then transition to full-screen by tapping the arrows.
  • Return from full-screen by tapping the arrows (does not pause playback) or the cross (pauses playback).
  • The layer is not visible anymore.
• The demo has been enhanced with corresponding use cases reproducing the issue.
• PiP otherwise works as before in all use cases testable in the demo.

Hints

• We don't support display of several VideoView at the same time with PiP support. This includes two use cases:
  • The same player is shared by two video views: Enabling PiP support for one view prevents the other video view from displaying a mirror of the content.
  • Two players and two video views: Enabling PiP support for both views makes only one view display the video.
• The cause of the issue on our side is that a layer is shared through a PiP controller. In the above configurations this leads to the layer being removed from one of the video view superlayers since it is stolen by the other video view (adding a layer implicitly removes it from any parent layer).
• Fix ideas:
  • Only borrow layers with no superlayer (but PiP restoration seems not to be smooth anymore, with the transition not being animated properly).
  • Associate PiP layer with context that requested it, preventing a layer from being stolen. Any other view with PiP enabled has no PiP. Probably better but needs investigation.
• We can only have one view enabled for PiP but the following is a valid use case: view A and view B are enabled for PiP, only B supports PiP as a result. When dismissed A should then be able to support PiP.
• Remark: If fixed the issue Minor visual glitch in the multi-instance demo #707 will be likely fixed as well.

Tasks

• Update demo with single player - double views example. Reproduce the issue.
• Update demo with double player - double views example. Reproduce the issue.
• Update demo with view presenting another view and reproduce the issue:
  • Both supporting PiP.
  • Presenting supporting PiP.
  • Presented supporting PiP.
• Fix the issue. No glitch must occur.
• Go throuh all PiP use cases listed on ... and ensure nothing is broken (see Support advanced PiP integration #612).
• Check memory profile.
• Check if issue affects system video view as well (create dedicated task if a non-trivial separate fix is required).
• Remark to discuss: The following will not work as before but this should not be an issue: Open player from SRG list, enable PiP, toggle playlist. Was previously merging nicely. Remark: PiP must then be togglable again.

[defagos]

Fact: We cannot have two (or more) views displayed simultaneously, each with its own PiP controller. This prevents PiP from being automatically enabled when sending the app from background, probably because the system cannot pick the instance to use.

Remark

There is also an interesting canStartPictureInPictureAutomaticallyFromInline property we could provide support. This property makes it possible to automatically enable PiP, even when the view does not cover the whole screen. I quite think we could always enable this property when instantiating a PiP controller since, if PiP is not desired (not the main content), it should not be supported by a video view anyway.