Block device setting for Picture in Picture

Feature Requests
, ,
1

While using the Bitmovin implementation of Picture in Picture, the device setting to activate PiP by default is blocked by the SDK. But when we want a custom implementation, this blockage is removed. This results in behaviour we cannot control. We’d like an option in the Bitmovin SDK to still block this device setting, even though we are using our custom PiP logic. Right now this isn’t possible.

// Blocks device setting
BitmovinPlayer.PlayerConfig.playbackConfig.isBackgroundPlaybackEnabled = true
BitmovinPlayer.PlayerConfig.playbackConfig.isPictureInPictureEnabled = true

// Allows for custom PiP implementation, adhering device setting, activating PiP when we don't want to
BitmovinPlayer.PlayerConfig.playbackConfig.isBackgroundPlaybackEnabled = false
BitmovinPlayer.PlayerConfig.playbackConfig.isPictureInPictureEnabled = false

Screenshot 2022-12-22 at 09.58.19
Screenshot 2022-12-22 at 09.58.19612×643 52 KB

2

Hi,

In 3.32.0 we added a new PictureInPictureConfig where you can now configure the desired behaviour.

You can block this system setting by setting shouldEnterOnBackground to false.

A few notes on this:

  • The PictureInPictureConfig is part of a new PlayerViewConfig that can be passed to the PlayerViews initializer. The old playbackConfig.isPictureInPictureEnabled configuration was deprecated in favour of this new config.
  • This is only available from iOS 14.2 onwards.
  • If the system setting Start PiP Automatically is turned off, setting shouldEnterOnBackground to true also has no effect. The system setting has precedence in this case.

Hope that helps :slightly_smiling_face:

3

Hi David, thanks for your response.
As the new config is working fine for a regular PlayerView-instantiation, it doesn’t work with a custom implementation. This is easily reproducible with the Bitmovin example project with some changes posted by Alberto to achieve the custom implementation:

4

We discovered similar issues recently internally based on another request.

Unfortunately, custom PiP handling in combination with subclassing our PlayerView is not supported and results in unexpected behaviour. The problem with this is that our PlayerView does not know about the external PiP implementation and can not react accordingly.

Can you help me understand what is your use case for using a custom PIP implementation?

5

We use the subclassing of PlayerView for the management of the player controls inside of the PiP view. We’ve got usecases for disabling the seekbuttons:

controller?.requiresLinearPlayback

And disabling play/pause/stop button:

controller?.setValue(enabled ? 0 : 1, forKey: "controlsStyle")

Small implementations which wouldn’t be difficult to refactor for us if Bitmovin chooses to implement it in the SDK

6

Ok I see.

At least for the first use-case (requiresLinearPlayback) we introduced PictureInPictureConfig.showSkipControls to configure this.

I’m not sure if the second use-case is something we want to have in our SDK as there is no ‘official’ API to control the play/pause/stop button. I also wonder if Apple will let that through the review process.

7

The "controlsStyle" alteration is indeed not completely intended behaviour by Apple, but they are still approving our builds so far. We couldn’t find any other, neater, solution. If you do know a different approach, we’re all open to it :slight_smile: