Blocked content handling PoC

[defagos]

As an editor I don't want users to be able to see content that I decided should be blocked (legal, commercial, geoblocking). As a developer I would like to have an implementation strategy that matches business needs.

Acceptance criteria

• Legal, commercial, etc. content is blocked.
• Geoblocked content is blocked outside Switzerland.

Hints

• On Apple platforms the following works more or less (some images can be seen when seeking is smooth):

  queuePlayer.smoothCurrentTimePublisher(interval: .init(value: 1, timescale: 10), queue: .main)
        .receiveOnMainThread()
        .sink { [queuePlayer] time in
            if time.seconds > 120 && time.seconds < 240 {
                queuePlayer.seek(to: .init(value: 240, timescale: 1))
            }
        }
        .store(in: &cancellables)

• On Apple platforms we could implement a smooth boundary time publisher to implement this mechanism, whether a forbidden time is crossed during normal playback or reached through seeking (we could combine traditional boundary time observation with our seekTimePublisher, e.g.). We should update (or implement) the existing issue we already have if this makes sense.

• We probably should use a PlayerItemTracker to implement blocked segment tracking. Note that this requires us to implement selective tracker selection, since we don't want such trackers to be disabled when playing SRG SSR content. Maybe having two tracker lists (optional and mandatory) would provide a simpler API (to be discussed).

• Maybe we should investigate how we can associated metadata (and notify the surrounding app about its changes) with blocked intervals. An app should be able to observe blocked information and respond appropriately (e.g. display a corresponding message).

Remark

We might have issues with standalone mode and geoblocking. In the following example, no blocked segments are returned for the full-length, which makes the content incorrectly playable. This should be reported to the backend team (Letterbox and Pillarbox players are all affected).

Tasks

• [ ] Investigate possible approaches.
• [ ] Implement the approach that best makes sense.
• [ ] Report geoblocking issues with standalone playback to the backend team.

[defagos]

We implemented two PoCs with various tradeoffs. In the two cases we first extracted segments for the current chapter in the media composition.

First PoC: Player item tracker

We can use a PlayerItemTracker implementing a periodic time publisher to detect when a forbidden time range is reached.

Pros

• No API changes made in PillarboxPlayer. Our business need of handling blocked time ranges has no visible API impact on the player.

Cons

• Some forbiddden images can be briefly seen when seeking smoothly into forbidden ranges. This is due to the fact that we cannot change a seek target time from a player item tracker. Once a seek request has been made, and even if we detect we must seek somewhere else immediately, images from the first seek might still be seen.
• Cannot be integrated as interstitials on tvOS.

Remaining work

• We need to have a way to avoid such trackers to be disabled with isTrackingEnabled, as they are mandatory.

Second PoC: Support in player metadata

We can add forbidden time ranges to PlayerMetadata. This way we can observe time to detect when forbidden ranges are entered. Moreover we can have seeks directly prevent target times in forbidden ranges. For a better result the forbidden ranges must be provided to the QueuePlayer so that low-level seeks, no matter where they are made from, prevent access to forbidden regions.

Pros

• No forbidden images can be briefly seen. The only exception is when casting over AirPlay. In such cases we can still briefly seek into forbidden regions.
• Can be integrated as interstitials on tvOS (but not when casting over AirPlay).

Cons

• The PillarboxPlayer API must be changed to address a business use case that maybe makes sense only to us.

Strategy

We should likely discuss these two PoCs in a review involving business and packaging people:

• If briefly seing a few images is acceptable we should go with the first implementation as it does not change the PillarboxPlayer API for an internal business need.
• Otherwise we should go with the second implementation.

In parallel we should have the packaging teams work on trimming blocked intervals from streams. When done we will then be able to remove the related code entirely.

[defagos]

After investigating how #845 could be implemented it appears that the second strategy offers a common formalism to handle credits as well as blocked intervals.

For this reason the business discussion about briefly seen forbidden frames is irrelevant. Still remains the discussion about how packaging could avoid forbidden images to be delivered entirely.