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

Add method to SimpleExoPlayer if a surface exists #2701

Closed
PaulWoitaschek opened this issue Apr 18, 2017 · 3 comments
Closed

Add method to SimpleExoPlayer if a surface exists #2701

PaulWoitaschek opened this issue Apr 18, 2017 · 3 comments

Comments

@PaulWoitaschek
Copy link

I'm using ExoPlayer in a RecyclerView and I'm clearing the surface in onViewRecycled. So I have to set it again in the onBindViewHolder.
However doing so each time onBindViewHolder is called seems very expensive. So I would like to know if the SimpleExoPlayeralready has a surface and skip setting it in that case.
I can't simply keep track if I set it as exoplayer seems to remove the surface itself when it gets destroyed.

Also after scrolling a few times up and down the player stops playback. After a manual seekTo it works again.

@ojw28
Copy link
Contributor

ojw28 commented Apr 19, 2017

I don't really understand this request. If you pass a SurfaceView or TextureView then SimpleExoPlayer will indeed clear the surface if it's destroyed, but it will also re-instate the surface if it's recreated, which should happen if/when the view becomes visible again. So I don't see SimpleExoPlayers handling of the surface lifecycle as problematic. You can also completely avoid having SimpleExoPlayer manage the surface lifecycle by using setVideoSurface, passing the surface directly rather than the view that holds it. So I think tracking what you've set yourself should be sufficient.

It's more likely you're running into a pretty fundamental limitation of the underlying platform, which makes it difficult to switch the targeted surface without the player having to skip ahead to the next keyframe in the media. This is discussed in a few issues already on the tracker, for example #318. #677 tracks our efforts to make switching surface smoother. We think we should be able to release a good solution for Marshmallow+ in the near future. For earlier versions of Android there's just not a whole lot we can do.

@ojw28
Copy link
Contributor

ojw28 commented Apr 19, 2017

Note: My comment about skipping ahead to the next keyframe applies to the case where you don't disable the video renderer. If you do disable the video renderer (e.g. as in #2703) then this is not correct, but in that case you take the hit of having to re-buffer instead.

@ojw28
Copy link
Contributor

ojw28 commented May 2, 2017

Closing because I still don't understand the request, and clarification has not been provided.

@ojw28 ojw28 closed this as completed May 2, 2017
@google google locked and limited conversation to collaborators Aug 31, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants