I'm having problems with seeking video.
My application should resume video from place where it was stopped last time. So I do this:
videoView.seekTo(bookmark);
videoView.start(); However when it plays I hear sounds form beginning of video for about 1-2 sec. And only after that video seeks to the right position. This behavior is reproducible on HTC Nexus One, HTC G1, HTC evo. But on Samsung galaxy tab all plays normally. Anybody had similar problems? Is this bug HTC-specific? Thanks in advance.
It is definitely not specific to your phone. I am having the same issue on an HTC Incredible. The seekTo works but there is an audio glitch from the beginning of the clip. Based on the results trying to implement the custom VideoView I guess I won't go to the trouble. I am now going to see if I can mute the very beginning of the clip. I'll report back here if I succeed.
Well, I have given up on this. The only way I have found to mute the beginning of the clip is to mute the phone entirely, which would mute the background music as well. I will assume that this will be fixed sometime in the future since this is a known issue:
http://code.google.com/p/android/issues/detail?id=9135
Issue 9135: MediaPlayer/VideoView and SeekTo before initial playback starts from beginning for few millisecs
I guess that can be a reason:
from api doc
Although the asynchronuous seekTo(int) call returns right way, the actual seek operation may take a while to finish, especially for audio/video being streamed. When the actual seek operation completes, the internal player engine calls a user supplied OnSeekComplete.onSeekComplete() if an OnSeekCompleteListener has been registered beforehand via setOnSeekCompleteListener(OnSeekCompleteListener).
now Videoview does not have OnSeekCompleteListener exposed and it sucks, but Videoview is just a wrapper class for Mediaplayer and SurfaceView
Related
I have an app which plays a lot of video files. It's been all good on every phone and tablet I've tested on. I just tested on an Acer Chromebook and the first few frames (maybe up to a 1/4 second) are being dropped on all video files, so the video appears to start just slightly beyond 0. Some of the videos have audio that starts immediately and so it's obvious to the user that the video is clipped at the start. I'm wondering if anyone else has seen this issue, maybe on a Chromebook or other device and if there is some simple way to deal with it?
There is absolutely nothing fancy about my code. I'm using VideoView, preload the video with setVideoURI(), then call videoView.start() on a button press.
Thanks!
This problem only appears if I make a call to seek(0). So rather than doing that to replay the video I have to load the video each time it's requested. That workaround resolves the problem.
Whenever I call setDisplay() on a MediaPlayer while it is playing (i.e. setDisplay(null) when backgrounding a video to play audio in the background) the media player stutters and rewinds for some small amount of time. Once I comment out these lines, essentially restricting the application to only play audio, these stutters and consequent rewinds no longer occur. Any ideas what the issue may be?
EDIT:
So I think the cause of the problem might be android media player choosing the closest keyframe to resume from on each display change because it can''t render inbetween keyframes. Any ideas?
I'm creating an android app in which I have to precisely know when playback starts/pauses/buffers etc (I need to play a video only for specific time). However PlaybackEventListener is calling not proper callbacks. For example on Sony Xperia S here is the order of callback which are called by listener: BUFFERING, BUFFERING, PLAYING, BUFFERRING, BUFFERING (and here is when the playback actually starts, yes not on PLAYING callback).
On the other phone (not so popular - Telefunken Diamon) callbacks are called more randomly sometimes it's: BUFFERING, BUFFERING, PLAYING (playback starts), but sometimes the same as on Xperia S.
On the emulator - GenyMotion API 4.3 the order and callbacks are proper - BUFFERING, BUFFERING, PLAYING (playback starts).
I was trying with loadVideo(String, int) method and cueVideo(String, int) method, but the result is the same. However what I did notice is that when I'm using those methods without initial offset (second parameter) like loadVideo(String) the order on all three phones looks the same: BUFFERING, BUFFERING, PLAYING, but I need to seek the video, so anyone dealed earlier with something like that and can help? Thanks in advance!
Can anyone shed light on the following problem? The android native mediaplayer seems to now use the PTS (Presentation Time Stamp) values in the transport stream to determine playback in the stream, rather than a simple counter. This behavior appeared to start with the 4.4.3 update. The symptoms of this are as follows:
The MediaController displays unhelpful values and no longer is able to be used to skip ahead or move back for streams that do not have PTS reset to zero in the first segment.
The MediaPlayer returns incorrect values for the getCurrentPosition() api call. Instead of starting at zero, it seems to use the PTS value, and ends returning multiple hours after only 1 second of playback, for example.
I am wondering if anyone can explain this behavior, or can reference a "feature" from this release of KitKat. The closest filed bug in Android I found is here. The player is used in a VideoView. The same playlists report expected numbers for getCurrentPosition() in earlier 4.4.2.
Thanks
It sounds like you're running into the same problem that a lot of people are having with HLS native video on 4.4.3 and 4.4.4: https://code.google.com/p/android/issues/detail?id=70877.
I haven't seen the presentation time stamp mentioned yet so it would be very helpful if you could share your findings on the bug ticket.
I try to implement a simple media player to play an audio stream from an external URL. Pretty simple I guess. Tried to implement this sample from Androïd dev site http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/media/MediaPlayerDemo_Audio.html
It works just fine with 2.1.
Then, with 2.2 it gets weird. Starts just well, but takes almost 10 seconds to stop.
With 2.3, it's not better. This time might take up to a minute to start playing, but stops OK.
Does anyone have a clue why ? I also did try the prepareAsync way with the listner, but it never get called. Any help would be appreciated at this point. Thanks !
Register setOnInfoListener() and control start buffering, end buffering and so on.
Look at the android documentation link