ERROR_CODE_IO_UNSPECIFIED error on HLS stream

[needz]

Version

Media3 1.2.1

More version details

Started happening since version 1.2.0-alpha01
Issue is not happening in version 1.1.1 of ExoPlayer Demo App

Devices that reproduce the issue

ADT-3
Sony Android TV
nVidia Shield Android TV

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes
Normal operation can be tested in version 1.1.1

Reproduction steps

Play given HLS stream in ExoPlayer Demo App

Expected result

Media plays without playback error

Actual result

Media stops after 10 seconds (end of chunk) with ERROR_CODE_IO_UNSPECIFIED

Found out this portion of TsExtractor.java messes things up (line 328 - 334):

// Send a synthesised empty pusi to allow for packetFinished to be triggered on the last unit. for (int i = 0; i < tsPayloadReaders.size(); i++) { TsPayloadReader payloadReader = tsPayloadReaders.valueAt(i); if (payloadReader instanceof PesReader) { payloadReader.consume(new ParsableByteArray(), FLAG_PAYLOAD_UNIT_START_INDICATOR); } }

Event Logs:

EventLogger E playerFailed [eventTime=9.61, mediaPos=8.74, window=0, period=0, errorCode=ERROR_CODE_IO_UNSPECIFIED androidx.media3.exoplayer.ExoPlaybackException: Source error at androidx.media3.exoplayer.ExoPlayerImplInternal.handleIoException(ExoPlayerImplInternal.java:704) at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:677) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:223) at android.os.HandlerThread.run(HandlerThread.java:67) Caused by: androidx.media3.exoplayer.upstream.Loader$UnexpectedLoaderException: Unexpected IllegalArgumentException: null at androidx.media3.exoplayer.upstream.Loader$LoadTask.run(Loader.java:443) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.lang.Thread.run(Thread.java:923) Caused by: java.lang.IllegalArgumentException at androidx.media3.common.util.Assertions.checkArgument(Assertions.java:51) at androidx.media3.exoplayer.source.SampleQueue.commitSample(SampleQueue.java:821) at androidx.media3.exoplayer.source.SampleQueue.sampleMetadata(SampleQueue.java:655) at androidx.media3.exoplayer.hls.HlsSampleStreamWrapper$HlsSampleQueue.sampleMetadata(HlsSampleStreamWrapper.java:1762) at androidx.media3.extractor.ts.H262Reader.consume(H262Reader.java:195) at androidx.media3.extractor.ts.PesReader.consume(PesReader.java:147) at androidx.media3.extractor.ts.TsExtractor.read(TsExtractor.java:399) at androidx.media3.exoplayer.hls.BundledHlsMediaChunkExtractor.read(BundledHlsMediaChunkExtractor.java:72) at androidx.media3.exoplayer.hls.HlsMediaChunk.feedDataToExtractor(HlsMediaChunk.java:503) at androidx.media3.exoplayer.hls.HlsMediaChunk.loadMedia(HlsMediaChunk.java:467) at androidx.media3.exoplayer.hls.HlsMediaChunk.load(HlsMediaChunk.java:424) at androidx.media3.exoplayer.upstream.Loader$LoadTask.run(Loader.java:420) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)  at java.lang.Thread.run(Thread.java:923)  ]

Media

Sent to e-mail

Bug Report

• You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

[Nelsun]

Hi. I had same issue.
Found that is caused by H262Reader.packetFinished "extra added code - compared to old working versions"

@OverRide
public void packetFinished(boolean isEndOfInput) {
checkStateNotNull(output); // Asserts that createTracks has been called.
if (isEndOfInput) {
@C.BufferFlags int flags = sampleIsKeyframe ? C.BUFFER_FLAG_KEY_FRAME : 0;
int size = (int) (totalBytesWritten - samplePosition);

 output.sampleMetadata(sampleTimeUs, flags, size, 0,  null);

}

}

in working versions method is empty
This adds extra bytes to output, but then SampleQueue.commitSample
checkArgument(offsets[previousSampleRelativeIndex] + sizes[previousSampleRelativeIndex] <= offset);
fails because current offset is larger that reported.

[icbaker]

@tianyif @dsparano The change highlighted above in #1126 (comment) was also introduced in #419 (specifically 550bc5b), similar to the discussion in #1150 (comment).

[dsparano]

@icbaker thanks, yes I'm looking at various HLS streams trying to find a solution that doesn't miss the last AU and doesn't break some of the HLS cases. Anyway it looks like we need more HLS tests.

[dsparano]

@needz can you please copy here the url of the HLS stream to reproduce this issue? ditto @Nelsun

[dsparano]

I think the root cause of this issue is that the solution from #419 kind of assumes that Access Units don't span across multiple HLS segments (which instead happens here).

The HLS spec here says:
"The server SHOULD attempt to divide the source media at points that support effective decode of individual Media Segments, e.g., on packet and key frame boundaries."
so by using the word SHOULD for this, makes AUs across segments actually legal :(

Unfortunately, from TsExtractor, PesReader and the individual parsers (H262, etc) I don't think there is a way to determine whether the "EndOfInput" case is for ex. on the very last segment of a VOD HLS (in which case we should output the sample) or on a VOD intermediate or live segment (in which case we should not output the sample). I'm open to suggestions @icbaker

[needz]

@needz can you please copy here the url of the HLS stream to reproduce this issue? ditto @Nelsun

@dsparano, sorry, but my link is private and it seems to die over time. Send me your e-mail, so I can forward it to you.

[Nelsun]

@needz, @dsparano
https://tvplus-static-content.s3.eu-central-1.amazonaws.com/stream/hls/tep_hls/test2.m3u8
Here are the same static samples.
The manifest contains 2 dummy segment entries at start to shift the real for playback.

[dsparano]

@needz @Nelsun I think this branch should fix this issue, can you please try your side?

[Nelsun]

@dsparano - Yes. Playback is fine with this branch.

[needz]

@needz @Nelsun I think this branch should fix this issue, can you please try your side?

@dsparano, For me it's also working with these particular fixes. Will this commit be included in the later versions? Thanks!

[rohitjoins]

Hi @needz,

#419 has been rolled back and the issue should be resolved now.