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

AudioTrack: Discontinuity detected and Video Freezes, audio and subtitle works fine #5323

Closed
nishantkp opened this issue Dec 28, 2018 · 9 comments
Assignees

Comments

@nishantkp
Copy link

Hi,

I have a really strange issue.

Configuration I am using:

ExoPlayer + DRM content + IMA + Video Length 45-50 minutes

ExoPlayer Version : 2.9.2

Issue:

All works good.
Only time issue occurs is when when user is playing a content with more than two AdBreaks (let say video has a mid-roll) and presses fastForward button.
When user presses FF button, and if it hits the AdBreak. Ad plays as expected no issue there. But when user rewinds after the Ad, ExoPlayer is unable to play content before the AdBreak.
Audio and subtitles are there but video is frozen all the time till it hits the AdBreak, after that it works fine.

After the AdBreak, FF and RW buttons are working as expected but after if the user presses FF again and hit the Ad and it it tries to rewind the content before the Ad, same issue repeats.

On the top of that, from the log it shows this error message when user tries to forward and rewind in the frozen part of video.

E/AudioTrack: Discontinuity detected [expected 23219, got -51958000]
E/AudioTrack: Discontinuity detected [expected 23219, got -29759000]
E/AudioTrack: Discontinuity detected [expected 23219, got -6145000]

I am really not sure what's going on.

@nishantkp nishantkp changed the title AudioTrack: Discontinuity detected and Video Freezes, audio fr AudioTrack: Discontinuity detected and Video Freezes, audio and subtitle works fine Dec 28, 2018
@ojw28
Copy link
Contributor

ojw28 commented Jan 2, 2019

Can you provide better reproduction steps, to allow us to see what you're seeing? In particular some sample content and an ad tag. I tried playback of content with more than two ad breaks, and it worked fine for me.

@nishantkp
Copy link
Author

Hi @ojw28,

My apologies for not being clear,

ExoPlayer is used for TV and FF and RW action is achieved through listening to remote control events, KeyEvent.KEYCODE_MEDIA_FAST_FORWARD and KeyEvent.KEYCODE_MEDIA_REWIND

public boolean dispatchKeyEvent(KeyEvent event) {
        if (event.getKeyCode() == KeyEvent.KEYCODE_MEDIA_FAST_FORWARD &&
                event.getAction() == KeyEvent.ACTION_DOWN) {
            fastForward();
            return true;
        }
        if (event.getKeyCode() == KeyEvent.KEYCODE_MEDIA_FAST_FORWARD &&
                event.getAction() == KeyEvent.ACTION_DOWN) {
            rewind();
            return true;
        }
        ...
        ...
        ...
        super.dispatchKeyEvent(event);
    }

Steps to reproduce,

  1. Use seekTo() for the fast-forward and rewind, like

Fast Forward

long mForwardRewindPosition = 0L;
void fastForward() {
        mForwardRewindPosition = exoPlayer.getCurrentPosition() + (exoPlayer.getDuration() / 100);
        mForwardRewindPosition = Math.min(mForwardRewindPosition, exoPlayer.getDuration());
        exoPlayer.seekTo(exoPlayer.getCurrentWindowIndex(), mForwardRewindPosition);
    }

Rewind

void rewind() {
        mForwardRewindPosition = exoPlayer.getCurrentPosition() - (exoPlayer.getDuration() / 100);
        mForwardRewindPosition = Math.max(mForwardRewindPosition, 0);
        exoPlayer.seekTo(exoPlayer.getCurrentWindowIndex(), mForwardRewindPosition);
    }
  1. Press DPAD-Fast Forward till the seek hits to AdBreak.

  2. Let the Ad play.

  3. After Ad is done, hit DPAD-Rewind button to play the content before the Ad.

Actual Result

Audio and subtitles are working as expected but video is frozen all the time even you can see the progress.
Video will continue to resume playback automatically once the progress hit the ad break (the one we just played).

And at the same time if you check the log, you will find this error lines,

E/AudioTrack: Discontinuity detected [expected 23219, got -51958000]
E/AudioTrack: Discontinuity detected [expected 23219, got -29759000]
E/AudioTrack: Discontinuity detected [expected 23219, got -6145000]

Hope it will reproduce the issue.

@ojw28
Copy link
Contributor

ojw28 commented Jan 2, 2019

Can you provide better reproduction steps, to allow us to see what you're seeing? In particular some sample content and an ad tag.

@nishantkp
Copy link
Author

Hi,

sample video URL is,

http://www.bok.net/dash/tears_of_steel/cleartext/stream.mpd

and AdTag is,

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=

@ojw28
Copy link
Contributor

ojw28 commented Mar 6, 2019

I can't reproduce this in the demo app, even using 2.9.2 specifically. Could you try again to see if the issue is resolved (it's theoretically possible a change in IMA on the server side fixed this)?

If it still reproduces for you, could you provide a bit more information. In particular, a full bug report, and if possible a video showing the issue reproducing in our demo app, so that we can make sure we're doing exactly the same thing. Thanks!

@tonihei
Copy link
Collaborator

tonihei commented May 7, 2019

Closing because no further information was provided.

@tonihei tonihei closed this as completed May 7, 2019
@nishantkp
Copy link
Author

nishantkp commented Jun 13, 2019

Hi @ojw28,

It's been quite a while.

ExoPlayer Version : 2.10.1

I have proper reproduction steps now,

I am able to reproduce it with demo-app too.

Steps to reproduce,

Use AndroidTV or something which can be controlled via remote control.
I am also able to produce the same thing in phones/tablets as well.

  1. Install the app
  2. Open the demo app
  3. Go to IMA sample ad tags
  4. Play VMAP pre-, mid and post-rolls, single ads
  5. Let it play the pre-roll, after that select the progress-bar and start scrubbing after the mid-roll. Mid-roll will play just fine.
  6. Now scrub to the left before mid-roll, content will frizz, but you can still see the progress indicator and timings go forward even audio will play just fine.
  7. Video will play just fine after it hits the mid-roll.

Please find this drop-box link for better clarity,

https://www.dropbox.com/s/scbsm4kbr5gin1m/Video%202019-06-13%2C%202%2044%2001%20PM.mov?dl=0

@tonihei
Copy link
Collaborator

tonihei commented Jun 14, 2019

Thanks for the extra information and reproduction steps! It's now pretty clear that it's a duplicate of #6009 and it will be fixed soon.

@tonihei tonihei self-assigned this Jun 14, 2019
@nishantkp
Copy link
Author

@tonihei Thanks 👍

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
@google google locked and limited conversation to collaborators Sep 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants