Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Midroll ads freeze frame after playing #6009

Closed
meenukrishnamurthy opened this issue Jun 7, 2019 · 1 comment
Closed

Midroll ads freeze frame after playing #6009

meenukrishnamurthy opened this issue Jun 7, 2019 · 1 comment
Assignees
Labels

Comments

@meenukrishnamurthy
Copy link

[REQUIRED] Content description

Play a video with midroll ad,seek beyond the point of midroll ad,then the midroll ad is played and the video playing resumes after ad.If we seek backward the frame freezes.

[REQUIRED] Link to test content

Video Url : http://184.72.239.149/vod/smil:BigBuckBunny.smil/playlist.m3u8
Ads url : https://pubads.g.doubleclick.net/gampad/ads?sz=640x480&iu=/124319096/external/ad_rule_samples&ciu_szs=300x250&ad_rule=1&impl=s&gdfp_req=1&env=vp&output=vmap&unviewed_position_start=1&cust_params=deployment%3Ddevsite%26sample_ar%3Dpremidpost&cmsid=496&vid=short_onecue&correlator=

[REQUIRED] Version of ExoPlayer being used

Version : Exoplayer 2.9.6.I have also checked with the 2.10.0 version.Same issue exists

[REQUIRED] Device(s) and version(s) of Android being used

Honor View 10,API 28

@tonihei
Copy link
Collaborator

tonihei commented Jun 13, 2019

I can reproduce a slightly different problem using the same reproduction steps, but I think they both have the same underlying reason.

Under the given setup, we end up with negative renderer timestamps and not all platform decoders handle negative timestamps well. In my case, the decoder made rounding errors, changing the frame timestamps by 1 microsecond each, which results in a lot of dropped frames after the seek. I guess the "frozen" frame is a similar problem based on how the Honor View decoder is handling the negative timestamps.

ojw28 pushed a commit that referenced this issue Jun 18, 2019
We are currently queuing periods in a way such that the new start position
lines up with the end of the previous period (to ensure continuous playback).
However, if the start position of the new period is larger than the total of
all previously played period durations, we may end up with negative renderer
timestamps when seeking back to the beginning of this new period. Negative
timestamps should be avoided as most decoders have problems handling them
correctly.

This change forces a renderer reset if we detect such a seek to a negative
renderer time and also resets the renderer offset to 0 every time all
renderers are disabled, as this is the only time where we can savely change
the offset of an existing media period.

Also, if playback starts with an ad, we choose the content position as
renderer offset to prevent the whole issue from occurring for the seek-behind-
midroll case.

Issue:#6009
Issue:#5323
PiperOrigin-RevId: 253790054
ojw28 pushed a commit that referenced this issue Jun 19, 2019
We are currently queuing periods in a way such that the new start position
lines up with the end of the previous period (to ensure continuous playback).
However, if the start position of the new period is larger than the total of
all previously played period durations, we may end up with negative renderer
timestamps when seeking back to the beginning of this new period. Negative
timestamps should be avoided as most decoders have problems handling them
correctly.

This change forces a renderer reset if we detect such a seek to a negative
renderer time and also resets the renderer offset to 0 every time all
renderers are disabled, as this is the only time where we can savely change
the offset of an existing media period.

Also, if playback starts with an ad, we choose the content position as
renderer offset to prevent the whole issue from occurring for the seek-behind-
midroll case.

Issue:#6009
Issue:#5323
PiperOrigin-RevId: 253790054
@ojw28 ojw28 closed this as completed Jun 20, 2019
@google google locked and limited conversation to collaborators Oct 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants