Repository navigation
ERROR_CODE_IO_UNSPECIFIED error on HLS stream #1126
Description
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 bugreportto android-media-github@google.com after filing this issue.
Activity
[-]ERROR_CODE_IO_UNSPECIFIED error on HLS stream since version 1.2.0-alpha01[/-][+]ERROR_CODE_IO_UNSPECIFIED error on HLS stream[/+]Nelsun commentedon Mar 7, 2024
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);
}
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 commentedon Mar 7, 2024
@tianyif @dsparano The change highlighted above in #1126 (comment) was also introduced in #419 (specifically 550bc5b), similar to the discussion in #1150 (comment).
dsparano commentedon Mar 8, 2024
@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 commentedon Mar 8, 2024
@needz can you please copy here the url of the HLS stream to reproduce this issue? ditto @Nelsun
dsparano commentedon Mar 13, 2024
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 commentedon Mar 13, 2024
@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 commentedon Mar 13, 2024
@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 commentedon Mar 14, 2024
@needz @Nelsun I think this branch should fix this issue, can you please try your side?
Nelsun commentedon Mar 14, 2024
@dsparano - Yes. Playback is fine with this branch.
needz commentedon Mar 15, 2024
@dsparano, For me it's also working with these particular fixes. Will this commit be included in the later versions? Thanks!
rohitjoins commentedon Apr 9, 2024
Hi @needz,
#419 has been rolled back and the issue should be resolved now.