playbackPause (0ms) before ad breaks

[tonihei]

All diagrams in the appendix with non-stitched ad breaks show an "playbackPause(0ms)" event together with adBreakStart. This is never explained anywhere and doesn't seem to make much sense. Can you comment on the purpose of these and add proper explanations if necessary?

[gheikkila]

The reason for this is that the main content is conceptually paused, and then the ads start to play. After the ads the main content then starts to play again. To make the monitoring logic consistent a pause event should always be produced when the main content is paused and replaced by other content, even if in some cases the pause time will be zero.

[tonihei]

Isn't that what the "adBreakStart" event is already indicating? There is no conceivable way adBreakStart does not pause the main content, so adding another playbackPause is redundant. It also makes it more difficult to distinguish "playbackPause" events due to actual user-initiated pause commands from these ad-related events.

[mlevine84]

WG needs to discuss this further with player companies.

[tonihei]

I can only speak for Android's ExoPlayer, but there is no pause event for ad insertion in any case. Server-side stitching is a continuous stream anyway and client-side ad insertion is a smooth transition from content to ad without a 'pause' in the player sense. There is only a discontinuity event (i.e. adBreakStart) notifying you of the transition to or from ads.

[mlevine84]

Luther and Heffernan will review this comments and come back to the WG with a proposal.

[heff]

I can see where 0ms would confuse people. I'll write a up a proposal but here's some notes:

Isn't that what the "adBreakStart" event is already indicating?

It could, and then you would need Startup Time logic that accounts for both adBreakStart and pause events changing the state, as opposed to just a pause event. So far we've chosen to only treat adBreakStart as a signal that the content is changing, not also required to understand the current playback state.

It also makes it more difficult to distinguish "playbackPause" events due to actual user-initiated pause commands from these ad-related events

With the HTML5 video element you already can't tell the diff between a user-initiated pause and an API initiated pause. And you can't really squash a pause event so that it doesn't happen just because it's redundant. I'm guessing the same goes for iOS.

but there is no pause event for ad insertion in any case

Are you sure that's true with client-side ads? Visible delays between the content and a client-side ad are pretty common, on every platform. If there's no way to measure that time with ExoPlayer, it's not a good thing for our purposes.

[tonihei]

Are you sure that's true with client-side ads? Visible delays between the content and a client-side ad are pretty common, on every platform.

ExoPlayer stitches multiple pieces of content (or ads) together and sends the media samples as a continuous stream so that the decoders don't actually see a difference. That's why there is literally no delay at all as long as we can use the same decoder. For cases where the delay is unavoidable, e.g. because the video formats are different and we need to switch decoders, the player events are a state change to "buffering" (at the same time as "adBreakStart") and then back to "playing". There is still no "pause", because there is no intention to stop playback at any time.

[heff]

Ok great, so buffering is the event we'd use for this. That's inline with a conversation we had in the group today and we may move that direction, calling it a "stall" (i.e. buffering) rather than a pause+starting up again, seeing as that seems closer to the viewer's experience of it.

[njadia]

@heff will propose for WG to review.

[mlevine84]

WG agreed to accept Steve's proposed diagram change to "non-stitched" diagram.