AudioTrack: Discontinuity detected

[tipoc123]

[REQUIRED] Searched documentation and issues

ExoPlayer issues.

[REQUIRED] Question

Can you answer my question?

Links:
#5853 (comment)
#5853 (comment)

[icbaker]

Copying question, including bug report:

I have the same issue. Exoplayer 2.9.6 plays HLS video fine, but Exoplayer 2.10.* shows multiple errors (and video hangs at that points) :

E AudioTrack: Discontinuity detected [expected 99124410, got 100959077]

Sorry, no publicly available link.
In both cases the same device:
Android 6.0.1 STB GIEC MP1113 (chip Amlogic s905x)

ADB Bugreport (ExoPlayer 2.10.0): bugreport.txt

[tipoc123]

Any news?

[andrewlewis]

@tipoc123 Sorry for the delay. Please could you provide a test stream we can use to reproduce this in the ExoPlayer demo app? It looks like the audio presentation timestamps in the stream don't match with what we'd expect them to be based on the amount of decoded audio, so are you sure the stream is valid?

[tipoc123]

Please could you provide a test stream we can use to reproduce this in the ExoPlayer demo app?

I've made dump http://stand.netup.tv/downloads/T4711.zip, but the problem is not reproduced on that dump. Also, you can see bugreport.txt above.

[CristianMG]

Hi

I have the same problem, I can't reproduce this problem always, when I set "playbackParams" with reproduction speed fast the audio stream cuts and sounds like a whale. Is like a mix of slow speed and grave pitch.

In my log I can see this
Discontinuity detected [expected 656985396, got 656706757]

Maybe there is any strange in the audio stream?

I have the 2.9.0 version

This is a problem because the users reports error but I haven't any crash or ANR. I can't know how big the problem is.

Thanks you for your support.

Any update or reference to workaround?

[CateyesLin]

I have the same problem.
I test of the same HLS video url transformed by AWS MediaConvert service.
It's not a public video. I'm sorry for that I cannot provide the video publicly.

It was tested on 3 different devices and all the device can reproduce randomly.

• Set-Top Box:
  • TOP HaTV
  • RockTek X3
• Mobile
  • LG Nexus 5X

The video has tested in 2 origin, reference to the same video file source:

• Akamai
• AWS CloudFront

This issue were happen in both connection type of the same set-top box:

• Ethernet
• WiFi

Usually, it is hard to reproduce the issue. But sometimes will reproduce several times in a minute.

I tested this issue several times. The symptom are:

• It will reproduce at different position randomly of the same video.
• If always happens during changing video segments. And I use partial load of a video file.
• It was easier reproduce when the networking is not highly stable

Thanks for the supporting.

[stevemayhew]

@andrewlewis we have reproduced this at a couple of installations with live playback. While it looks like there are short audio segments in the playback, nothing really stands out as a big PDT jump. Will keep you all informed and post our analysis in this bug.

AudioTrack: Discontinuity detected [expected 1012508034, got 1000518700]

The STB is an SEI (AmLogic), but we have also seen it on an Arris (Broadcom based) This is almost a 12 second PTS in the sample (or the audio track is 12 seconds ahead), similar to what @CateyesLin is reporting, the issue goes away if you backup over the spot and play again.

I'm going to put some logs around the pause() / play() and see what I can find. Repeated re-buffering, caused by the connection issues @CateyesLin describes, may be exacerbating the issue.

The code I'm running has un-marked discontinuity checking, so it is not possible to queue audio samples so grossly out of the time range of the segment.

[andrewlewis]

Not sure if it will help much but this calculation is based on ExoPlayer's model of what input buffer timestamp is expected based on audio written so far, so in theory there isn't any device-specific code affecting this (though of course it may depend on something like what stream is selected for a device). For your example the upstream source must be providing an audio sample that has a presentation timestamp ~ 12 s earlier than what's expected.

[andrewlewis]

@stevemayhew Did you discover anything from the extra logging? Thanks.