Displaying last frame of previous video when preloading new one.

[tprochazka]

I found that ExoPlayer has the same issue like described here
http://stackoverflow.com/questions/25660994/clear-video-frame-from-surfaceview-on-video-complete

I tried to call player.stop() and then player.prepare() but during prepare period player still display the last frame of previous video and it looks weird. Is there any way how to force clean the SurfaceView before new one will start rendering? I don't know if it is bug or normal behavior.

I'm testing r2.0.2

[ojw28]

The easiest way to do this is simply to make some other completely black view visible on top of the surface. We already do this in SimpleExoPlayerView prior to the first frame being displayed, and also in the case that video output is disabled (either via the selector in the demo app, or as a result of playlist transition from video to audio-only). The black view is called shutterView in that class.

We should probably provide a mechanism to manually close the shutter, and/or a mechanism to close the shutter automatically at the start of a prepare() call. Although whether you'd want to do the latter depends a bit on what the prepare() call is for. If you're calling prepare() to retry after a playback error, for example, then you probably wouldn't want to close the shutter, since you'd expect to be resuming playback from the currently visible frame anyway.

[ojw28]

Marking as an enhancement to track supporting this with SimpleExoPlayerView. Note however that you can pretty easily do something like this in your app without any library support. The SimpleExoPlayer.VideoListener.onRenderedFirstFrame callback will indicate to you the correct moment to hide the black view and hence make the surface visible.

[tprochazka]

Thanks for reply. And yes I already thought about this solution.
But I'm curious when it is not possible to easily fix it directly in the Player when I call stop() method.

If you're calling prepare() to retry after a playback error, for example, then you probably wouldn't want to close the shutter, since you'd expect to be resuming playback from the currently visible frame anyway.

Maybe better would be if player will have auto recovery functionality or there will be a special method which will recovery playback and prepare() will be used just of play new different stream.

But maybe, as I told at he beginning. The blank screen should be maybe just in the situation when I call stop() and then prepare() if I call just prepare() the shutter should not hide SurfaceView.

[ojw28]

We'll probably implement this by closing the shutter in prepare if the third argument is true. Currently this argument is called resetTimeline, but it would be renamed to a more general resetState as part of the change. Note that the one-argument version of prepare sets the third argument to true by default.

[ojw28]

I think this is probably fixed in dev-v2. Could you give it a try and see?

[tprochazka]

If I understand add true as the last parameter of prepare should be enough?
I'm trying it on the latest version commit from dev-2 branch ant there is no change.
I still see one frame from previous video before new start playing.
It is necessary something else?

[ojw28]

Just passing true as the last argument to prepare should be sufficient. You can simulate something equivalent in the demo app by:

1. Changing the third argument to prepare be true in PlayerActivity.
2. Start playback of a piece of media.
3. Toggle device into airplane mode using pull down drawer. Wait for playback to fail.
4. Seek to a different position. Turn airplane mode off using pull down drawer.
5. Hit the "Retry" button.

You should see the view go black. The first frame displayed should be from the new position (i.e. from thew new source provided to the player in the final step). This is what I see, which suggests this is working correctly?

[tprochazka]

I'm not waiting on any fail. I'm just calling .stop(), then .prepare() and .setPlayWhenReady().
And after prepare() I still see last frame from old video.

[ojw28]

I don't think it's relevant. The above is just a way to trigger the same behavior. If you still have an issue then please provide as source a way for us to reproduce the issue, ideally as a small patch to the demo app.

[tprochazka]

I found workaround. I set the visibility gone for whole view and display it again in the AbstractExoPlayerListener. onPlayerStateChanged() if the state is ExoPlayer.STATE_READY.

I will try the demo app, there should happen to same when you switch to the different item from the playlist on the same instance of player simply by calling .stop() and prepare() with new one video.