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

Unhandled ArrayIndexOutOfBoundsException during live HLS playback when media sequence unexpectedly changes to zero #2249

Closed
gpinigin opened this issue Dec 22, 2016 · 5 comments
Assignees
Labels

Comments

@gpinigin
Copy link
Contributor

gpinigin commented Dec 22, 2016

Description

Unhandled ArrayIndexOutOfBoundsException during live HLS playback when media sequence unexpectedly changes to zero. First segment in new index file has no EXT-X-DISCONTINUITY tag added (according to HLS spec absence of tag may lead to playback error)

Reports gathered with Fabric show that negative index is close to value of last known media sequence.

Version

ExoPlayer v2.1.1

Stack trace

Fatal Exception: java.lang.ArrayIndexOutOfBoundsException: length=12; index=-4310639
       at java.util.ArrayList.get(ArrayList.java:310)
       at java.util.Collections$UnmodifiableList.get(Collections.java:1050)
       at com.google.android.exoplayer2.source.hls.playlist.HlsPlaylistTracker.adjustPlaylistTimestamps(HlsPlaylistTracker.java:371)
       at com.google.android.exoplayer2.source.hls.playlist.HlsPlaylistTracker.access$1300(HlsPlaylistTracker.java:40)
       at com.google.android.exoplayer2.source.hls.playlist.HlsPlaylistTracker$MediaPlaylistBundle.processLoadedPlaylist(HlsPlaylistTracker.java:465)
       at com.google.android.exoplayer2.source.hls.playlist.HlsPlaylistTracker$MediaPlaylistBundle.onLoadCompleted(HlsPlaylistTracker.java:422)
       at com.google.android.exoplayer2.source.hls.playlist.HlsPlaylistTracker$MediaPlaylistBundle.onLoadCompleted(HlsPlaylistTracker.java:381)
       at com.google.android.exoplayer2.upstream.Loader$LoadTask.handleMessage(Loader.java:355)
       at android.os.Handler.dispatchMessage(Handler.java:111)
       at android.os.Looper.loop(Looper.java:194)
       at android.os.HandlerThread.run(HandlerThread.java:61)
       at com.google.android.exoplayer2.util.PriorityHandlerThread.run(PriorityHandlerThread.java:40)
@ojw28
Copy link
Contributor

ojw28 commented Jan 2, 2017

I think you're confusing two separate topics. Use of the EXT-X-DISCONTINUITY tag allows various properties of the media segments to change (e.g. the encoding parameters). It does not make it OK to reset the media sequence number to zero, which is something that should never happen. The spec says this about the media sequence number:

Its value MUST be incremented by 1 for every Media Segment that is removed from the Playlist file; it MUST NOT decrease or wrap. Clients can malfunction if each Media Segment does not have a consistent, unique Media Sequence Number.

Marking this as a bug, but only because the exception isn't handled and causes process death, which isn't desirable. We'll fix this to cause a playback failure instead.

@ojw28 ojw28 added the bug label Jan 2, 2017
@gpinigin
Copy link
Contributor Author

gpinigin commented Jan 3, 2017

You are right, thank you for pointing out to this aspect.

Marking this as a bug, but only because the exception isn't handled and causes process death, which isn't desirable. We'll fix this to cause a playback failure instead.

It was the main intention.

@ojw28
Copy link
Contributor

ojw28 commented Jan 3, 2017

For the stack trace to occur as in this issue report, it looks like a required condition is:

newPlaylist.mediaSequence < oldPlaylist.mediaSequence

And also that:

newPlaylist.isNewerThan(oldPlaylist)

Else the method would have returned at this line.

Are you still able to reproduce the issue? If so, can you take a look and see why isNewerThan is evaluating to true in this case? The only way I can see this happening is if the new playlist not only has media sequence set back to 0, but if it also has an end tag appended when the old one didn't. Is that what's happening? If not, what is? Thanks.

@ojw28 ojw28 assigned ojw28 and unassigned AquilesCanta Jan 3, 2017
@gpinigin
Copy link
Contributor Author

gpinigin commented Jan 4, 2017

If so, can you take a look and see why isNewerThan is evaluating to true in this case? The only way I can see this happening is if the new playlist not only has media sequence set back to 0, but if it also has an end tag appended when the old one didn't.

End tag is appended to the new playlist also. I think appending end tag is the only reason why isNewerThan returns true

Just for clarification – due streaming service malfunction in some rare cases client is being redirected from live HLS stream to static HLS VOD. VOD playlist doesn't contain any segments from the preceding playlist.

@ojw28
Copy link
Contributor

ojw28 commented Jan 4, 2017

Our plan for handling this case is to create a new playlist consisting of the old playlist with the end tag appended (i.e. just treat the playback as though it's ended).

ojw28 added a commit that referenced this issue Jan 4, 2017
Issue: #2249

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143555467
@ojw28 ojw28 closed this as completed Jan 4, 2017
@google google locked and limited conversation to collaborators Jun 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants