Trickplay monitoring

[spenglerpeter]

We see some needs poping out on trickplay monitoring. These needs often refers to some specific use cases:

• Media and advertisement measurement, that may be a legal constraints
• Consolidate data
• Monitor trickplay actions during ads (e.g. beaconing)

There are already some keys that provides such information

• State [sta] : describing the current playback state
• Timestamp [ts] : timestamp at which the associated event occurred

We suggest the following additions:

• seekStart [sks] : Only available if state(sta)=k Defines where the seeking actions has been started. The letter explains the unit. R relative to beginning of manifest and in ms ex: R3600 A absolute in Epoch ex: A1727958000000

• seekEnd [ske] : Only available if state(sta)=k Defines where the seeking actions ends. The letter explains the unit. The letter explains the unit R relative to beginning of manifest and in ms ex: R3600000 A absolute in Epoch ex: A1727958000000

• pause [pau] : The elapsed time between the time pause has been triggered and the time playback restarted Only available after end of pause (resume): state(sta) was egal to “a” now egal to “p” OR on each keep-alive request in case the player sends keep-alive during the pause,

[PCaponetti]

I'm not very familiar with trickplay monitoring, but I wonder how much overlap this has with state/interval CMCD mode where we have the player send CMCD data on state change. You get a state change to seeking mode (k) for seeking start and away from it for seeking end. This requires state on the analysis end to know previous state (i.e. know we are moving from playing to seeking for example).

The missing bit is the time in the video. We have timestamp, but that is absolute (since epoch), not relative.

Would you like to change this proposal to only add timestamp in the media's timeline? If so, note the overlap with #142