Open defagos opened 2 weeks ago
We can likely have a quite simple implementation which observes only AVPlayerItem
changes:
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).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.
I think it would be probably great to:
SuspendingClock
to each player for time-measurements with a single shared reference frame.AVPlayerItem
.AVPlayerItem
with the content URL.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.
The event publisher approach seems interesting. It can also be later extended by adding native events produced by AVMetrics
.
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
Hints
isPlaybackLikelyToKeepUp
. Maybe we should zip events to wait for both and return the maximum value.Tasks
ItemProperties
. Expose it in thePlayerProperties
.AssetContent
. InCurrentTracker
access this timing later fromitem.content
and somehow provide it to the player item tracker.