Improve handling of discontinuities for TS streams

[LSDsl]

Exoplayer 2.11.2 (and any prev. version too)

com.google.android.exoplayer2.ExoPlaybackException: com.google.android.exoplayer2.upstream.Loader$UnexpectedLoaderException: Unexpected OutOfMemoryError: Failed to allocate a 100012 byte allocation with 66032 free bytes and 64KB until OOM
        at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:394)
        at android.os.Handler.dispatchMessage(Handler.java:98)
        at android.os.Looper.loop(Looper.java:154)
        at android.os.HandlerThread.run(HandlerThread.java:61)
     Caused by: com.google.android.exoplayer2.upstream.Loader$UnexpectedLoaderException: Unexpected OutOfMemoryError: Failed to allocate a 100012 byte allocation with 66032 free bytes and 64KB until OOM
        at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:421)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
        at java.lang.Thread.run(Thread.java:761)
     Caused by: java.lang.OutOfMemoryError: Failed to allocate a 100012 byte allocation with 66032 free bytes and 64KB until OOM
        at com.google.android.exoplayer2.source.SampleQueue.commitSample(SampleQueue.java:688)
        at com.google.android.exoplayer2.source.SampleQueue.sampleMetadata(SampleQueue.java:497)
        at com.google.android.exoplayer2.extractor.ts.H264Reader$SampleReader.outputSample(H264Reader.java:470)
        at com.google.android.exoplayer2.extractor.ts.H264Reader$SampleReader.endNalUnit(H264Reader.java:452)
        at com.google.android.exoplayer2.extractor.ts.H264Reader.endNalUnit(H264Reader.java:231)
        at com.google.android.exoplayer2.extractor.ts.H264Reader.consume(H264Reader.java:148)
        at com.google.android.exoplayer2.extractor.ts.PesReader.consume(PesReader.java:136)
        at com.google.android.exoplayer2.extractor.ts.TsExtractor.read(TsExtractor.java:338)
        at com.google.android.exoplayer2.source.ProgressiveMediaPeriod$ExtractingLoadable.load(ProgressiveMediaPeriod.java:982)
        at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:391)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)

[christosts]

Can you please provide a link to the test content so that we can test? The ticket description mentions a the stream has an error, can you please provide more info about that? Also, what device (model and Android OS version) you are using?

(We have an issue template here that covers what is usually needed to start looking at an issue).

If you can't share test content publicly, please send them to dev.exoplayer@gmail.com using the subject "Issue #6983".

Thanks

[LSDsl]

Amlogic p281, Android 7, Sent link to video to mail

[kim-vde]

Could you please resend a link to the content? It is outdated.

[master255]

@LSDsl Maybe it's a double? #6647
You need to correct the settings. Close the bug, if that's the truth.

[LSDsl]

@master255 It's not the same problem.

[kim-vde]

I investigated the issue and here is what I found out:

• The error is caused by a sudden drop in the presentation timestamps (pts), going from 2 705 940 000 to 302 400.
• This causes the timestamps computed for the samples to become negative. As a consequence, ExoPlayer keeps loading data without interruption, causing an OutOfMemory error.
• The packet for which the pts is dropping does not have a set discontinuity_indicator in its header. There is a discontinuity in the continuity_counter though. An explanation to this is that the packet containing the discontinuity_indicator could have been dropped (hence, the discontinuity in the continuity_counter).

I tried to fix the issue by resetting the TimestampAdjuster when a discontinuity (indicated by the discontinuity_indicator or by the continuity_counter) is encountered with the following code:

payloadReader.seek();
for (TimestampAdjuster timestampAdjuster : timestampAdjusters) {
  long lastAdjustedTimestampUs = timestampAdjuster.getLastAdjustedTimestampUs();
  timestampAdjuster.reset();
  timestampAdjuster.setFirstSampleTimestampUs(lastAdjustedTimestampUs);
}

It fixes the issue for your stream but it breaks seeking for other TS streams.

I will mark this issue as an enhancement to improve the handling of discontinuities in TS streams. Note that this enhancement is low-priority for our team at the moment.

To fix the issue on your side, you could try to apply the patch mentioned above in a local version of ExoPlayer.

[stevemayhew]

I investigated the issue and here is what I found out:

• The error is caused by a sudden drop in the presentation timestamps (pts), going from 2 705 940 000 to 302 400.
• This causes the timestamps computed for the samples to become negative. As a consequence, ExoPlayer keeps loading data without interruption, causing an OutOfMemory error.
• The packet for which the pts is dropping does not have a set discontinuity_indicator in its header. There is a discontinuity in the continuity_counter though. An explanation to this is that the packet containing the discontinuity_indicator could have been dropped (hence, the discontinuity in the continuity_counter).

The continuity_counter is ignored in HLS TS segments (Origin server packager is supposed to break segments at continuity boundaries)? Is this a simple TS file you are trying to play or a segment in HLS.

[LSDsl]

a simple TS file, not HLS