Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attempting to play a specially encapsulated TS format video in ExoPlayer results in a pointer out-of-bounds exception. #1476

Open
Chadewik-junao opened this issue Jun 20, 2024 · 3 comments
Assignees
Labels

Comments

@Chadewik-junao
Copy link

Problem Description

I've integrated ExoPlayer into my application to play TS format videos from a server URL. However, I encountered an exception that prevents the video from playing correctly. The exception is an ArrayIndexOutOfBoundsException thrown while trying to retrieve the buffered position.

##Version
Media3 1.3.0

Error Log

Here is the complete stack trace of the error:

Playback error
androidx.media3.exoplayer.ExoPlaybackException: Unexpected runtime error
at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:636)
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: java.lang.ArrayIndexOutOfBoundsException: length=2; index=2
at androidx.media3.exoplayer.source.ProgressiveMediaPeriod.getBufferedPositionUs(ProgressiveMediaPeriod.java:395)
at androidx.media3.exoplayer.source.MaskingMediaPeriod.getBufferedPositionUs(MaskingMediaPeriod.java:203)
at androidx.media3.exoplayer.MediaPeriodHolder.isFullyBuffered(MediaPeriodHolder.java:153)
at androidx.media3.exoplayer.ExoPlayerImplInternal.shouldTransitionToReadyState(ExoPlayerImplInternal.java:1806)
at androidx.media3.exoplayer.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:1053)
at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:510)
at android.os.Handler.dispatchMessage(Handler.java:102at android.os.Looper.loop(Looper.java:223at android.os.HandlerThread.run(HandlerThread.java:67)

My code looks like this

player=new ExoPlayer.Builder(context).setLooper(mHandlerThread.getLooper()).setLoadControl(loadControl).build();
DataSource.Factory dataSourceFactory = new DefaultDataSource.Factory(context);
MediaItem mediaItem = MediaItem.fromUri(mVideoUri);
mediaSource = new ProgressiveMediaSource.Factory(dataSourceFactory).createMediaSource(mediaItem);
player.setMediaSource(mediaSource );
player.prepare();

The video file cannot be uploaded due to copyright reasons.

How do I fix it ? Thank you for your assistance.

@tonihei
Copy link
Collaborator

tonihei commented Jun 24, 2024

Thanks for reporting the error. Could you share the media file that reproduces the issue? It looks not quite clear how this problem can happen, so I think we can only debug this further if we can reproduce it ourselves. You can send a link to android-media-github@google.com with "Issue #1476" in the subject if you don't want to share it here.

@Chadewik-junao
Copy link
Author

I have already sent the problematic media file. Hope it is helpful for solving the issue. Thank you.

@tonihei
Copy link
Collaborator

tonihei commented Jun 25, 2024

Thanks for sharing the file. It seems this is caused by adding tracks in the TS file that are only advertised later in the file after ExoPlayer already finished its initial preparation step. I'll add a fix to the class that currently breaks to ignore such tracks as they are unsupported.

copybara-service bot pushed a commit that referenced this issue Jun 25, 2024
Extractors should not report additional tracks once they called
ExtractorOutput.endTracks. This causes thread safety issues in
ProgressiveMediaPeriod where the array of sample queues is
extended while the playback thread accesses the arrays.

Detecting this problem early is beneficial to avoid unexplained
exceptions later one. In most cases where this may happen (namely
TS extractors finding new tracks), it's better to ignore the new
tracks instead of failing completely. So this change adds a
warning log message and assigns a placeholder output.

Note: The same workaround already exists in HlsSampleStreamWrapper
and MediaExtractorCompat.

Issue: #1476
#cherrypick
PiperOrigin-RevId: 646427213
tianyif pushed a commit that referenced this issue Jul 2, 2024
Extractors should not report additional tracks once they called
ExtractorOutput.endTracks. This causes thread safety issues in
ProgressiveMediaPeriod where the array of sample queues is
extended while the playback thread accesses the arrays.

Detecting this problem early is beneficial to avoid unexplained
exceptions later one. In most cases where this may happen (namely
TS extractors finding new tracks), it's better to ignore the new
tracks instead of failing completely. So this change adds a
warning log message and assigns a placeholder output.

Note: The same workaround already exists in HlsSampleStreamWrapper
and MediaExtractorCompat.

Issue: #1476
#cherrypick
PiperOrigin-RevId: 646427213
(cherry picked from commit 18e631f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 participants