Artifacts at playback when switching between SimpleExoPlayerViews

[botondbutuza]

Hi guys!

First off, fantastic work, I'm loving working with and exploring ExoPlayer. I am fairly new to it, but I've spent a good few hours researching my issue, and I haven't found an explanation/solution just yet.

I'm running ExoPlayer v2.0.4 on a OnePlus One with Android 6.0.1, API 23.

I have two SimpleExoPlayerViews, and two SimpleExoPlayers, both set up to play HLS live streams. I basically need to preview a stream in one player, then seamlessly switch over to the main player if I decide I want to watch it.

The issue I'm having is that when I switch from the preview view to the main one, the video plays instantly, which is great, but I'm getting gray artifacts on the screen for anything between a second to four seconds. It's like the first frame isn't being rendered completely, and it's lagging behind, if that makes any sense. Here's some screencaps: http://iob.imgur.com/uYGg/J7eJiitZvy

My main workflow is as follows:

• SimpleExoPlayer 1 is playing in the main SimpleExoPlayerView player
• User clicks on button
• SimpleExoPlayer 2 is initialised and starts playing in the preview SimpleExoPlayerView player
• User clicks on button again
• Since player 2 is the stream we want to play, I just move player 2 to the main SimpleExoPlayerView (setPlayer())
• I tried releasing the old player before setting the new one, but have the same issue

Any ideas on why this happens and how I could mitigate it would be amazing!

Thanks!

[botondbutuza]

Just a small update - I tried switching to SurfaceView, and experience the exact same issue.

[botondbutuza]

I can confirm that the issue persists when switching over to the latest development branch.

Anyone have any ideas or pointers on what to investigate?

[ojw28]

Is the issue specific to the content you're trying to play, or does it happen with all content? Try playing this video in your setup, which is just a plain MP4, and see if it reproduces in that case.

[botondbutuza]

Good shout! I tried playing other m3u8 streams, as we'd only ever stream HLS, not MP4. The issue persists when switching between the following streams as well:

http://media.blacktrash.org/stsp.m3u8
https://d2zihajmogu5jn.cloudfront.net/bipbop-advanced/bipbop_16x9_variant.m3u8

The player looks much the same as in the screencaps above, with gray artifacts on the screen after the switch. It corrects after a few seconds.

I can send you my project with my HLS streams for you to have a look, if that'd be quicker than you trying to replicate the issue.

[botondbutuza]

Any update on this issue?

[ojw28]

I'm able to reproduce the issue (it actually reproduces with streams of any type). The problem occurs because we're not waiting for the next key-frame before rendering to the new surface, which we should be doing.

Fixing the issue will remove the corruption, but it will also mean that the switch wont be immediate any more because we'll be discarding frames from the point at which the switch occurs up to the next key-frame. The alternative is to re-buffer from the previous key-frame, which isn't great either.

In general instant surface switching is quite difficult due to the way the decoder is tied to the surface at the platform level. There are (non-trivial) solutions. See #318 for details.

[botondbutuza]

Thank you for the detailed response, it's great to understand the underlying problem with it! I'll look for other solutions in the meantime.

Is there an easy way for me to know how far away the next keyframe is while playing?

[PGSatrz]

@botondbutuza , have you tested the same assets with same version if Exoplayer on devices having Android 5.0 or lower version.

Please share your feedback after running this test.
Please check "#2009" which is kind of similar issues which we are facing on Samsung devices having 6.0.1 version.

Also, please share the details of the "software info" of the device on which you are testing.

Thanks

[jarnova]

Any updates on this? Is there any ETA for a fix or is there some workaround for this issue. This is the only issue with ExoPlayer v2 that is blocking us from updating from v1 at the moment.

[botondbutuza]

@jarnova We've reduced latency in switching between views by increasing the number of keyframes in our streams. If you have access to the streams, I'd suggest doing this.

[ojw28]

The change above makes V2 behave in the same way as V1 does. Which isn't ideal, as noted in my Nov 29th update to this issue above. It does at least remove any reason to not update from V1 to V2, since there is no longer anything that could be considered a regression here.

I'll go ahead and close this. Please give it a try on the dev-v2 branch. We're planning to cut a 2.2.0 release containing this fix sometime next week.