I get some lines like the following:
10-15 21:34:30.318 6996-20354/? I/NuPlayerRenderer: possible video time jump of 546ms (266286180 : 260922630) or uninitialized media clock, retrying in 10ms
10-15 21:34:30.328 6996-20354/? I/NuPlayerRenderer: possible video time jump of 536ms (266286180 : 260922630) or uninitialized media clock, retrying in 10ms
10-15 21:34:30.338 6996-20354/? I/NuPlayerRenderer: possible video time jump of 526ms (266286180 : 260922630) or uninitialized media clock, retrying in 10ms
10-15 21:34:30.348 6996-20354/? I/NuPlayerRenderer: possible video time jump of 516ms (266286180 : 260922630) or uninitialized media clock, retrying in 10ms
10-15 21:34:30.358 6996-20354/? I/NuPlayerRenderer: possible video time jump of 506ms (266286180 : 260922630) or uninitialized media clock, retrying in 10ms
When I use the Media Player to use as Live Wallpaper using WallpaperService.Engine.
#Override
public void onVisibilityChanged(boolean visible) {
super.onVisibilityChanged(visible);
Log.i("VideoWallpaperEngine", "onVisibilityChanged");
try {
if(visible)
mediaPlayer.start();
else
mediaPlayer.pause();
} catch (Exception e) {
e.printStackTrace();
}
}
While these lines are printed, the video is paused because (I think) he tries to synchronize the video and the audio!?
I am only interested in the video stream and not the audio so does someone have an idea how to skip this check and to simply continue playing the video? Is there a library to play a video (mp4) without this?
Many thanks in advance.
Solution: (by #VC.One)
Use an mp4 without audio line. See https://www.youtube.com/watch?v=YwT1FTRjRNQ to remove the audio line from a video using VLC player.
(of course, only if you don't need the audio part of your video)
Related
I want to implement loop video recording (e.g., DVR devices for vehicles/cars work this way).
MediaRecorder has setMaxDuration method:
After recording reaches the specified duration, a notification will be
sent to the MediaRecorder.OnInfoListener with a "what" code of
MEDIA_RECORDER_INFO_MAX_DURATION_REACHED and recording will be
stopped. Stopping happens asynchronously, there is no guarantee that
the recorder will have stopped by the time the listener is notified.
So when it reaches that "max duration" it stops recording but asynchronously and how can I start a new recording session if previous one can still be in progress?
Should I create a new instance of MediaRecorder for the next recording session? Will it work fine?
private val infoListener: MediaRecorder.OnInfoListener =
MediaRecorder.OnInfoListener { mr, what, extra ->
when (what) {
MediaRecorder.MEDIA_RECORDER_INFO_MAX_DURATION_REACHED -> {
// I want to start a new recording session
}
...
}
}
For a continuous recording application, setMaxFileSize() is more useful, because the MediaRecorder will send a MEDIA_RECORDER_INFO_MAX_FILESIZE_APPROACHING code to OnInfoListener, at which point your application can call setNextOutputFile() to set the next filename and allow the MediaRecorder to continue into the new file without stopping and restarting the recording from the application. If you know the video and audio bitrates, you can estimate the file size corresponding to your desired duration. It is will not be the exact duration, but still useful for accomplishing basic chunked recording.
Your application will need to keep track of the files you create and delete the old ones if you want to implement a circular recording scheme with a limited total storage size.
when mediaplayer play online video(video is big),I drag progress,progress is 50,and video loading stream is 30,when I use play.seekto(50)，I find stream stopping load ,video can not play,when video is smaller，This phenomenon does not occur，when video is bigger，this phenomeno occur, I don not konw what reason,seek help
You have to use scaling. progress bar 50 is like 50% of video. Depending on the streaming protocol used, get the length of the video (on demand case) and convert 50% of that length to ms as seekTo takes ms as the argument.
I have a number of mp3 files that I use with Android MediaPlayer to play from certain offsets.
Using seekTo() seems to stop at correct location. player.getCurrrentPosition() returns the correct offset, but in some cases the real position is off for as much as 200 ms. The files are about 3 minutes worth of recording and the incorrect offsets seem to appear at the end. Of some of the files.
I have the same effect either trying with Android 4.0.3 device or 4.3 emulator.
Anybody has experience with "finetuning" MediaPlayer offsets? Any experience why MediaPlayer might not be working correctly with some files? They are all CBR, stereo, some have sampling frequency 22050, some 44100, different bitrates.
I'm setting the offsets from another program and saving to mp3 tags, then in case of doubt verifying manually using Audacity. Audacity agrees with my estimate of what the correct offset is, MediaPlayer seems to disagree.
I'm aware that I could use AudioTrack with raw sound files and have a better control, however it might be impractical as there are many mp3 files, so using raw sound data will make pretty large application or many large data files.
The code is nothing fancy:
player.seekTo(start);
player.start();
CountDownTimer timer = new CountDownTimer(length, 100) {
#Override
public void onTick(long millisUntilFinished) {
if (player!=null) setInt(R.id.nLocation, player.getCurrentPosition());
}
#Override
public void onFinish() {
if (player!=null) {
if (player.isPlaying()) {
player.pause();
}
setInt(R.id.nLocation, player.getCurrentPosition());
player.stop();
player.release();
player = null;
}
}
};
timer.start();
I did not manage to find the rule why the MediaPlayer interprets offset (seekTo) differently for a group of MP3 files. For example when creating a new MP3 file with the same parameters from Audacity+Lame (MPEG1, Layer III, 44100 Hz, 192 Kb/s) it worked perfectly.
However:
this can be reproduced - rip MP3 file using Windows Media Player, settings: MP3, 192 kb/s [added when edited]
I found the workaround that seems to work for any recording.
The background - in order to tell MediaPlayer to play from certain offset, I store certain data in MP3 tags. I use a separate program to set up the playback (in frames): Label A, start frame=1000, length=100 frames, Label B, start #1500 etc. Now when I need to play it back, I read the MP3 headers, determine the frame length, for example 26.12245 ms/frame and calculate the offset (1000 frames will be 26122 ms).
The workaround is to store in MP3 tag also the frame count and length in ms (or pass through again and count the frames). Then when start MediaPlayer, compare MediaPlayer.getDuration() (MediaPlayer estimate) with the duration stored in MP3 tag. Then adjust the frame size:
adjustedFrameSizeMs = realFrameSizeMs + (player.getDuration()-storedDurationMs)/storedframeCount;
In my case (for the files with incorrect offset) the adjusted frame length always was between 26.08 and 26.09 ms (instead of 26.12245).
I attempted to try see if this is because Android plays the recording quicker (so it estimates the "real time", not the time according to frame size and frame count). It seems that it really does plays quicker. But even quicker than its own estimate. For example a recording of about 1 hour:
my estimate: 2448 s
MediaPlayer: 2444 s (4 sec difference)
Audacity: 2442 s (here we are in disagreement)
Foobar: 2448 s (another witness that agrees with my estimate :-)
MediaPlayer, real play time: 2438 s
The real playtime was 6 s (0.25%) less than MediaPlayer own estimate. Another attempt on a different sample gave the same percentage difference. However the fact that Audacity and Foobar did not always agree with my estimates, does not let me put all the blame on MediaPlayer.
I try to stream (progressive e.g: http://server.com/video.mp4)
when i use the standard google mediaplayer (VideoView from android package) and register an onBufferingUpdateListener then i get the bufferpercentage that refers to the download state of the hole video. This player has also a loading view where i can see the buffer state.
This bufferpercentage and view shows me how much of the video has been downloaded.
Now when i use the Vitamio player, the onBufferingUpdateListener shows me after a few seconds 99 percent of buffering and there is no loading view too. And when i pause the playback it stops buffering immediately instead of continue buffering like the google videoview does. This is very usefull if you have a slow http stream.
Is there a way to make the vitamio-videoplayer buffer the videofiles in the same way as the google videoplayer does?
thank you
daniel
Sorry i posted that question as wrong user. Here the Answer of what i tried:
VideoView (android default - just plays few video formats) from inside the android.widget and from io.vov.vitamio.widget (vitamio - plays most video formats) package has the same structure. In both you can register an OnBufferingUdateListener that returns the bufferstate in percent:
videoview.setOnBufferingUpdateListener(new io.vov.vitamio.MediaPlayer.OnBufferingUpdateListener() {
public void onBufferingUpdate(io.vov.vitamio.MediaPlayer mp, int i) {
Log.v(TAG, "Buffer percentage done: "+i);
}
});
or with the android default VideoView:
videoview.setOnBufferingUpdateListener(new android.media.MediaPlayer.OnBufferingUpdateListener() {
public void onBufferingUpdate(android.media.MediaPlayer mp, int i) {
Log.v(TAG, "Buffer percentage done: "+i);
}
});
If i use android.widget.VideoView the buffer percentage slowly increases until it reaches 100% - The video file has been downloaded completely. And it continues updating BufferingUpdate when i press the pause button.
When i use io.vov.vitamio.widget.VideoView the percentage reaches 100% within seconds. Then the video starts and the OnBufferingUpdateListener never gets called again (when i call getBufferPercentage it is always at 99 percent. That seems to be the reason). And as i sayed: It seems to stop buffering when i press the pause button.
I think the buffering works different in vitamio. But that's crap. Especially when i stream videos from the web and the video datarate is higher than the download speed i need to prebuffer the video by pressing pause and wait until it has downloaded enough data to watch it smoothly. Hope you got what i mean. thank you
I recently observed a very weird problem with MediaPlayer playing an mp3 file. I'm running this code (mPlayer is a MediaPlayer):
Log.d(TAG, "Pausing");
try {
mPlayer.pause();
Log.d(TAG, "Paused");
} catch (IllegalStateException e) {
Log.w(TAG, "exception pausing player");
}
The weird thing is that if I'm close to the end of the audio file, the player sends a completion notification to my OnCompletionListener a short time after the above code completes. (I haven't pinned down exactly how close I have to be, but it's on the order of 1/4 second.) For instance, here's a typical logcat output when this occurs:
05-27 17:23:43.439: DEBUG/Player(266): Pausing
05-27 17:23:43.487: DEBUG/Player(266): Paused
05-27 17:23:43.838: WARN/Player(266): Audio completed (state=PAUSED)
Note that the warning line (logged from my OnCompletionListener), comes over 300 ms after the call to pause() returned!
The result is that the media player enters the PlaybackCompleted state when I don't expect it. This screws up the behavior of my code (as well as start(), which restarts from the beginning instead of playing the last little bit of the file).
This has happened on emulators from 1.6 through 2.3 and on at least one device running 2.2. Does anyone know about this problem and what to do about it?
The mediaplayer runs in a separate thread and you have to wait until the ui thread and the mediaplayer's thread have synced. So the delay is normal. It may be possible that the player really completes the file because of your pause-command reaching the player too late. Try what happens with a longer audio-file.
Another problem which might come up is other code seeking beyond the end of the track after the pause-command. What's the code of your listener?