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.
Related
So I have an app that plays a video.
And I have a time sync server for setting the datetime of the device. It seems that whenever I call SystemClock.setCurrentTimeMillis(millis) the video stops.
I am using android.media.MediaPlayer.MediaPlayer() object to play the video?
Has anyone else experienced this? I was planning on creating a watchdog thread that just monitors the current duration. But just wanted to know if anyone had come across this already?
Yes, I came across the same situation on some devices. Probably hardware libs use the system time clock in the in decoding or av sync implementation; it happens. Only solution on those devices was to stop/restart the MediaPlayer. But it probably depends on the implementation of the lower levels.
I'm developing android application using Mediaplayer class that plays a song using a url. The problem is that the returned value after calling
mp.getDuration()
is larger than the actual duration of the song.
for example the song has a duration of 4.3 but in my application it gives that it equals 4.6
Can you give more details about your working environment (android version, file format, ...)?
The MediaPlayer is quite buggy. Surely you are experiencing one bug regarding some specific format. Have a look to the open issues in this topic.
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
This is a tough one :/
I'm making a music-based Android game a la Audiosurf. It works all nice except a few seconds before end of a song (that is being played with a normal MediaPlayer) the music stops aprubtly and the whole game (including UI) freezes for several seconds.
Each time that happens I see an "AudioHardware pcm playback is going to standby"-error in logcat.
Googling has led me to the conclusion that
this could be a HTC Hero specific issue (cannot be reproduced on emulator or other devices)
this message is normally logged when a http stream isn't fast enough for MediaPlayer
Audio in Android sucks in general
As I am decoding the mp3 with the NDK + libmpg123 for audio analysis already I might aswell just play the audio myself (using a very ugly interface between NDK C code and an AudioTrack in Java).
Is there a fix/workaround for this bug or should I really go that way? (I only have limited time left to complete this project)
I appreciate every hint!
You might be stopping the music when you've buffered it all in your C code. Since the AudioTrack has a delay in it, you may need to wait longer for it to finish.
I'd need more detail about your code to help, though.
So, I know that this has been done with a few Android apps before, but I cannot for the life of me figure out how, since it's not currently possible through the API.
How does one adjust the playback rate of a sound played through MediaPlayer; either with or without adjusting the pitch is fine for now, though the latter is definitely preferred. If someone can point me in the direction of an open source app that I can use as guidance, that would also be fine.
Thanks in advance.
Looks like AudioTrack.setPlaybackRate should do the trick.
Setting it to half the sample rate of
the content will cause the playback to
last twice as long, but will also
result in a negative pitch shift.
Not sure if you can get a AudioTrack from MediaPlayer...
ExoPlayer from version 2.4 has support playback speed adjustment back to Android Jelly Bean (API level 16). I am using it in my app with another very useful feature - seamlessly loop audio.