Repository navigation
IllegalStateException when drainToEndOfStream when in tunneling mode #10847
Description
ExoPlayer Version
2.18.2
Devices that reproduce the issue
Model: TalkTalk STB
Os: Android
Version: 10
Devices that do not reproduce the issue
Fire TV Stick (2nd Gen) running Fire OS 5.2.9.2 (Tunneling was not enabled for this media, tried other media with tunneling enabled but the issue was not present)
Reproducible in the demo app?
Yes
Reproduction steps
Turn on tunneling ie in PlayerActivity:
trackSelectionParameters =
new DefaultTrackSelector.ParametersBuilder(/* context= */ this)
.setTunnelingEnabled(true)
.build();
As our media is over http you will need to allow clear text, so in an xml file in res/xml:
<network-security-config>
<base-config cleartextTrafficPermitted="true"/>
</network-security-config>
And in the android manifest of the demo app tag:
android:networkSecurityConfig="@xml/network_config"
Play the video to the end, where the crash should occur.
Expected result
The audio sink should be released successfully
Actual result
The following exception is thown:
playerFailed [eventTime=33.10, mediaPos=29.47, window=0, period=0, errorCode=ERROR_CODE_FAILED_RUNTIME_CHECK
com.google.android.exoplayer2.ExoPlaybackException: Unexpected runtime error
at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:621)
at android.os.Handler.dispatchMessage(Handler.java:103)
at android.os.Looper.loop(Looper.java:214)
at android.os.HandlerThread.run(HandlerThread.java:67)
Caused by: java.lang.IllegalStateException
at com.google.android.exoplayer2.util.Assertions.checkState(Assertions.java:84)
at com.google.android.exoplayer2.audio.DefaultAudioSink.writeBuffer(DefaultAudioSink.java:1159)
at com.google.android.exoplayer2.audio.DefaultAudioSink.processBuffers(DefaultAudioSink.java:1099)
at com.google.android.exoplayer2.audio.DefaultAudioSink.drainToEndOfStream(DefaultAudioSink.java:1259)
at com.google.android.exoplayer2.audio.DefaultAudioSink.handleBuffer(DefaultAudioSink.java:893)
at com.google.android.exoplayer2.audio.MediaCodecAudioRenderer.processOutputBuffer(MediaCodecAudioRenderer.java:706)
at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.drainOutputBuffer(MediaCodecRenderer.java:1905)
at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.render(MediaCodecRenderer.java:792)
at com.google.android.exoplayer2.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:994)
at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:495)
at android.os.Handler.dispatchMessage(Handler.java:103)
at android.os.Looper.loop(Looper.java:214)
at android.os.HandlerThread.run(HandlerThread.java:67)
]
Media
Media Url is sent via email
Bug Report
- You will email the zip file produced by
adb bugreportto dev.exoplayer@gmail.com after filing this issue.
Activity
tonihei commentedon Dec 8, 2022
Do you have any custom
AudioProcessors in your app? I can reproduce the error by adding a custom processor, but can't see a way to trigger the problem with the default processors only.tomjhall commentedon Dec 14, 2022
No this should be reproducible in the ExoPlayer reference application - we have not added a custom
AudioProcessorto the reference app. I have created a patch file (sending to you via email) for the Exoplayer reference app so that you can better see the changes/apply ittonihei commentedon Dec 21, 2022
I just checked the emails, but can't see anything related to this issue. Could you make sure to use "Issue #10847" in the subject line? Otherwise the email may get lost in some filters.
tomjhall commentedon Dec 22, 2022
I've resent the email
tonihei commentedon Jan 9, 2023
Thanks! It again wasn't forwarded by our filters, but I was able to dig it out regardless. (Need to investigate what's going on there, but yours seem to be the only "correct" email that wasn't forwarded to us).
tonihei commentedon Jan 9, 2023
It looks like your stream may cause this issue because it requires gapless trimming. This enables an
AudioProcessorfor the trimming (see my question above) and in some situations this may then run into this assertion. Will provide a fix for this!Handle AV sync timestamps when draining the audio sink during tunneling
Handle AV sync timestamps when draining the audio sink during tunneling
tonihei commentedon Jan 26, 2023
The problem is likely fixed by the commit above.