CODEWITHSUNDEEP
androidvideomedia-playersurfaceview
greg
greg

Reputation: 21

can a mediaplayer be restarted when the surfaceview is being recreated? (Android)

I have an activity (say activity A) which displays video using a mediaplayer, rendered in a surfaceview.
The use case is to pause the video, start another activity (say activity B), then come back to activity A.
Activity A is stopped but not destroyed when going to B, which is good.
The surface view (since not visibile) IS destroyed (as observed from the notification callbacks).
When coming back to activity A, and restarting the mediaplayer using start(), the media player does play back the audio, but video is not seen. Errors like this one are output on Logcat: 

11-16 18:14:44.532: ERROR/Overlay(8630): Error = Invalid argument from qbuf

Unfortunately, using the new instance of SurfaceHolder as provided by surfaceCreated() doesn't help (i.e. provides the same error).

I have read in various posts a solution would be to reset the mediaplayer and restart it completely, however it is not efficient, as the end user would have to wait for the whole player preparation cycle + seekTo last position within the stream.

As shown with the fact the audio plays back, it should be a matter of plumbing between the the video decoder and the new surfaceholder/view.

What should be the best solution (best = fastest) to resume video playback when resuming the activity?

Upvotes: 2

Views: 2580

Answers (4)

Minfang Tao
Minfang Tao

Reputation: 11

Under Android 4, it is possible (Sorry, I only have 2.3 and 4.0, I do not test it in 3.0). When you use Surface and mediaplayer, you can not change the surface for the mediaplayer. The same thing for the videoview.

If you print the log, you will find surfaceview was destroyed an created again when you go back from other app.

In Android 4.0 you can change the surface or surface holder for the mediaplayer.

Upvotes: 1

Greg
Greg

Reputation: 1

Thanks. Handling the fact the activity might be destroyed because the system needs resources would be ok.

I may go with the view on top. I ll need then to handle users pressing the back key to go back to the video...

From ht media player behavior it really seems something is missing to make it work as expected, i.e. Audio is back (which implies the demuxing of a/v is happening correctly), I would have guessed it s just a matter of plumbing between the video decoder and the video renderer.

Upvotes: 0

Ryan Reeves
Ryan Reeves

Reputation: 10249

Be careful because activity A can be killed by the OS while paused in the history stack and showing activity B. You should code to expect it.

If speed is important to you, you might consider not starting activity B, but rather hiding the videoview and showing another view in its place instead.

Upvotes: 0

Vinay
Vinay

Reputation: 4793

Can you try with VideoView as it comprises both Surface and MediaPlayer object

Upvotes: 0

Related Questions