one mpeg-ts file will drop many frames when play, maybe the extactor of it's audio has some issue

[liangqiujuan]

Hi,
when playing the local file diver1.ts, we can see the duration is 14s, but the real playing time is about 8s. Many frames is dropped and the log will print like this: "Unexpected audio track timestamp discontinuity: expected 3248000, got 3536000".
Even when I use extension-ffmpeg the problem is also exist.

The file diver1.ts has a audio track with mimeType audio/mpeg-L2 and has a video track with mimeType video/mpeg2.

other information:
ExoPlayer version number: The version we used is 2.12 , and the version 2.14.2 is still has this problem.
Android version: android 11
Android device: [Amlogic/ohm/ohm:11/RTT0.210618.002/58:userdebug/release-keys]

In the same device, the play is normal when using VLC player downloaded from Google playstore.

the test file and log: file_log.zip

[claincly]

we can see the duration is 14s, but the real playing time is about 8s

VLC is also showing the duration of 14s, maybe it's what's intended?

Did repro on my side. The track selection view:

      MediaCodecVideoRenderer [
        Group:0, adaptive_supported=N/A [
          [ ] Track:0, id=1/256, mimeType=video/mpeg2, res=720x576, supported=NO_UNSUPPORTED_TYPE
        ]
      ]
      MediaCodecAudioRenderer [
        Group:0, adaptive_supported=N/A [
          [ ] Track:0, id=1/272, mimeType=audio/mpeg-L2, channels=2, sample_rate=48000, supported=NO_UNSUPPORTED_TYPE
        ]
      ]

@kim-vde Could you take a look at this, is it with TS extractor, etc?

[liangqiujuan]

Hi claincly,
I add some log in TsExtractor.java and can see the log print:
3489 3546 D TsExtractor: sniff-,startposCandidate:0
Line 95: 08-13 10:09:08.133 3489 3546 D TsExtractor: seek,timestampAdjustersCount:1
Line 96: 08-13 10:09:08.133 3489 3546 D TsExtractor: seek,position:0
Line 97: 08-13 10:09:08.133 3489 3546 D TsExtractor: tsPayloadReaders posiontion:0
Line 98: 08-13 10:09:08.133 3489 3546 D TsExtractor: fillBufferWithAtLeastOnePacket-
Line 100: 08-13 10:09:08.138 3489 3546 D TsExtractor: fillBufferWithAtLeastOnePacket-
Line 101: 08-13 10:09:08.195 3489 3546 D TsExtractor: seek,timestampAdjustersCount:1
Line 102: 08-13 10:09:08.195 3489 3546 D TsExtractor: seek,position:0
Line 103: 08-13 10:09:08.195 3489 3546 D TsExtractor: tsPayloadReaders posiontion:0
Line 104: 08-13 10:09:08.196 3489 3546 D TsExtractor: tsPayloadReaders posiontion:1
Line 105: 08-13 10:09:08.196 3489 3546 D TsExtractor: fillBufferWithAtLeastOnePacket-
Line 107: 08-13 10:09:08.200 3489 3546 D TsExtractor: fillBufferWithAtLeastOnePacket-
Line 109: 08-13 10:09:08.200 3489 3546 D TsExtractor: fillBufferWithAtLeastOnePacket-
Line 111: 08-13 10:09:08.200 3489 3546 D TsExtractor: fillBufferWithAtLeastOnePacket-
Line 113: 08-13 10:09:08.200 3489 3546 D TsExtractor: fillBufferWithAtLeastOnePacket-
I add a demo apk with extension-ffmpeg, you can use this apk to play it.
apk-log.zip

[kim-vde]

The "Unexpected audio track timestamp discontinuity" error occurs when an audio sample duration does not match the timestamp of the next sample. Imagine you have an audio sample with timestamp 0 and duration 1 second. You would expect the next sample to have timestamp 1 second. The DefaultAudioSink compares the actual and expected timestamp value, and logs this error if the delta between these values is too large.

For the content provided, the expected value is smaller than the actual one, meaning that there are some "holes" between the samples. In this case, ExoPlayer concatenates the samples. That's why the duration of the audio is smaller than expected.

The reason of this issue could be that the sample format is s16p (planar signed 16 bit audio), but I am not sure. I will investigate more when I have time.

[liangqiujuan]

Hi，kim-vde
Thanks for your analysis.
can you have a solution of this issue?

[kim-vde]

Hi,

I have investigated the issue a bit more and the problem comes from the fact that some audio packets do not have an associated PTS. I am working on a fix in ExoPlayer to handle this case. It should be pushed to the repo in the following days.

[kim-vde]

I have just pushed a fix to dev-v2. It will be part of the next minor release.

I'll close the issue as your problem should be fixed. Please open a new one if you still encounter issues.

[liangqiujuan]

Thank you. It resolve the issue.