seek

Seek the content player, snapping to the nearest sync sample.

ExoPlayer defaults to EXACT seeking, which must decode from the preceding keyframe up to the target — on a post-break resume that showed up as a visible hole between the ad ending and content reappearing. Measured on a Galaxy Tab, adbreakend -> content playing: ~2.2s on VOD (1658ms of it seek recovery) and ~1.4s on live (1257ms). The gap arrived with the resume-seek itself: resolveResumePoint was dead code, so Android used to resume instantly — at the wrong position.

Frame accuracy buys nothing here. A DAI resume targets the CUE, which is where a break was inserted and therefore already at or near a segment boundary, and a live latency restore is recovering ~10s. Up to one GOP of drift is irrelevant against either.

Scoped rather than global: SeekParameters is a player-wide setting, and the integrator owns this player. The previous value is restored immediately, so the app's OWN seeks (DVR scrubbing, which never come through this adapter) keep exact behaviour.