Startup time

[defagos]

As a player developer I want to understand how fast content starts so that we can find ways to improve the user experience if needed.

Acceptance criteria

• The startup time is available in metrics, including data loading as well as startup time of the player itself.

Hints

• According to the WWDC 2019 Measuring and Optimizing HLS Performance session we should rely on timebase rate notifications to detect readiness to play. According to the experience, though, this value is very often (but not always) smaller than isPlaybackLikelyToKeepUp. Maybe we should zip events to wait for both and return the maximum value.

Tasks

• [ ] Use timebase rate change notification to detect playback readiness and internally provide the associated timing information to ItemProperties. Expose it in the PlayerProperties.
• [ ] Extract asset publisher delivery timing and provide it to AssetContent. In CurrentTracker access this timing later from item.content and somehow provide it to the player item tracker.

[defagos]

We can likely have a quite simple implementation which observes only AVPlayerItem changes:

1. When an item is becomes the current one it starts in a loading state (loading URL). Save this initial time.
2. When the item is replaced with an item having a playable URL, measure the time. The difference with the initial time describes how much time was required to fetch metadata.
3. When the item timebase rate notification is received (or maybe isPlaybackLikelyToKeepUp changes to `true, we still need to figure out which criterium is the best), measure the time. The distance with the previous measured time describes the time needed to prepare the content for playback (startup time).
4. The sum of both times is the total startup time.

Note that in playlists both times will be reduced because of pre-loading. This means such times describe the perceived user experience, not the actual technical time required for complete startup (except in the case a single item is played). While there exists a way to extract the time required for metadata retrieval, there is no such way to extract the time required for AVPlayerItem startup, so I guess this is the most consistent way of defining these times.

[defagos]

I think it would be probably great to:

• Associate a single SuspendingClock to each player for time-measurements with a single shared reference frame.
• Store interesting times in properties:
  • Player taking into account the loading AVPlayerItem.
  • Player taking into account the AVPlayerItem with the content URL.
  • Player ready (timebase notification or likely to keep up, depending on what we see fit).
• Then return the interesting duration as calculated property between these times.

[defagos]

Another option is to have something similar to AVMetrics, that means an event publisher for all interesting timing events, instead of storing values in properties. Our PlayerItemTracker protocol could then be expanded with a method called when an event is received.

Events could possibly include loading(time:), loaded(time:), ready(time:), maybe similar events for stalls.

[defagos]

The event publisher approach seems interesting. It can also be later extended by adding native events produced by AVMetrics.