I'm developing a video app, using video_player package. I want to repeat the videos n times. I'm doing this by adding listener and when video reaches the end, if the current repetition is not equal to the N, I simply call the _videoPlayerController.seekTo(Duration.zero), it works as expected in iOS, but in Android it takes some time to play it again, because of the buffer I guess. I have some logs. When I call the seekTo, first log is:
D/AudioTrack(26148): stop(59): called with 194560 frames delivered
After some time(3-4 seconds) the other logs come and video plays after these logs:
D/AudioTrack(26148): getTimestamp_l(60): device stall time corrected using current time 21442303047753
D/AudioTrack(26148): getTimestamp_l(60): stale timestamp time corrected, currentTimeNanos: 21440694441753 < limitNs: 21442169902753 < mStartNs: 21442230902753
W/AudioTrack(26148): getTimestamp_l(60): retrograde timestamp time corrected, 21442169902753 < 21442303047753
I'm not sure the problem in here is the buffering but if so, is there anyway to prevent buffering while using seekTo in android or is there any other way to achieve this functionality?
I'm thinking this problem come from the initial thread so if you call your first seek initial code in did dependencies method or you can try to wrap initial code to addpostframe call back with binding.
WidgetsBinding.instance?.addPostFrameCallback((timeStamp) {
_playController(index: 0, durationInSeconds: 5);
});
or try to call didChangeDepencies after the initState initialize.
#override
void didChangeDependencies() {
super.didChangeDependencies();
}
Related
I've been playing around with Flutter and trying to get it so I can record the front facing camera (using the camera plugin [https://pub.dev/packages/camera]) as well as playing a video to the user (using the video_player plugin [https://pub.dev/packages/video_player]).
Next I use ffmpeg to horizontally stack the videos together. This all works fine but when I play back the final output there is a slight delay when listening to the audio. I'm calling Future.wait([cameraController.startVideoRecording(filePath), videoController.play()]); but there is a slight delay in these tasks actually starting. I don't even need them to fire at the exact same time (which I'm realising is probably impossible), instead if I knew exactly when each of the tasks begun then I can use the time difference to sync the audio using ffmpeg or similar.
I've tried adding a listener on the videoController to see when isPlaying first returns true, and also watching the output directory for when the recorded video appears on the filesystem:
listener = () {
if (videoController.value.isPlaying) {
isPlaying = DateTime.now().microsecondsSinceEpoch;
log('isPlaying '+isPlaying.toString());
}
videoController.removeListener(listener);
};
videoController.addListener(listener);
var watcher = DirectoryWatcher('${extDir.path}/');
watcher.events.listen((event) {
if (event.type == ChangeType.ADD) {
fileAdded = DateTime.now().microsecondsSinceEpoch;
log('added '+fileAdded.toString());
}
});
Then likewise for checking if the camera is recording:
var listener;
listener = () {
if (cameraController.value.isRecordingVideo) {
log('isRecordingVideo '+DateTime.now().microsecondsSinceEpoch.toString());
//cameraController.removeListener(listener);
}
};
cameraController.addListener(listener);
This results in (for example) the following order and microseconds for each event:
is playing: 1606478994797247
is recording: 1606478995492889 (695642 microseconds later)
added: 1606478995839676 (346787 microseconds later)
However, when I play back the video the syncing is off by approx 0.152 seconds so doesn't marry up to the time differences reported above.
Does anyone have any idea how I could accomplish near perfect syncing when combining 2 videos? Thanks.
For example, when the user starts watching the stream, I will initialize the player and that starts playing from the latest position in the live stream. If the user then pauses the video they will be x seconds behind the latest stream position. I want to add functionality to allow them to seek directly the latest live position.
My current approach is to simply reinitialize the stream...
_videoPlayerController1 = VideoPlayerController.network('theUrl/index.m3u8');
_chewieController = ChewieController(
videoPlayerController: _videoPlayerController1,
autoPlay: true,
isLive: true,
autoInitialize: true,
);
However, as the two mentioned libraries heavily emphasize the need to call dispose() when finished with them I'm worried about creating memory leaks here. Is this approach okay?
I did try calling dispose() on them both before calling the above code...
_videoPlayerController1.dispose();
_chewieController.dispose();
Although that led to the following error 'A VideoPlayerController was used after being disposed. Once you have called dispose() on a VideoPlayerController, it can no longer be used.'
Does my approach lead to memory leaks and is there a better way to seek the latest live stream position?
I figured it out. The simplest way jump to the latest position in a live stream is to call:
_chewieController.seekTo(Duration(days: 30));
Under the hood, Chewie is calling the seekTo method on its videoController which is documented with the following:
/// If [moment] is outside of the video's full range it will be automatically
/// and silently clamped.
So it seems that if you don't know the streams latest position then you can pass in a Duration value that is much larger than what you expect the stream's latest position to be (30 days in this example) and the VideoController will set it's position to its latest known position.
Try the following code:
_videoPlayerController.seekTo(_videoPlayerController.value.duration);
I am writing a game using CreateJS and using CocoonJS to distribute. Within CocoonJS API are a couple of listener functions that allow callbacks when pausing and resuming of the game. The game's timer and (time-based) animations are driven by the Ticker event's "delta" property. The issue that I am having at the moment is, on resuming the game following on from pausing it, the timer will pick up from the time at which it paused plus the time spent whilst paused. For example, I pause the game after 20 seconds for exactly 4 seconds, on resuming the game the timer will carry on from 24 seconds (not 20 seconds, which is intended). I've tried storing the ticker event's "runTime" property before pausing and attempting to then set the ticker event's "runTime" to this stored value on resume, but this doesn't work.
A snippet of my original code (before tinkering) is like the following:
createjs.Ticker.setFPS(60);
createjs.Ticker.on("tick", onTick, this);
Cocoon.App.on("activated", function() {
console.log("---[[[[[ APP RESUMING ]]]]]---");
createjs.Ticker.paused = false;
});
Cocoon.App.on("suspending", function() {
console.log("---[[[[[ APP PAUSING ]]]]]---");
createjs.Ticker.paused = true;
});
onTick = function (e) {
if (!e.paused) {
animateUsingTicker(e.deltaTime);
countDownTimerUsingTicker(e.deltaTime);
//etc...
stage.update();
}
};
Can someone please assist me on this?
Many thanks
One really easy way to deal with this is to use Timer.maxDelta. For example, if you are targeting 60fps, you could set this to something like 32ms (double the expected delta), to prevent getting huge values back when resuming an app/game.
I'm using libspotify SDK, C library for win32.
I think to have a right setup, every session callback is registered. I don't understand why i can't receive the call for end_of_track, while music_delivery continues to be called with zero padding 22050 long frames.
I attempt to start playing first loading the track with sp_session_load; till it returns SP_ERROR_IS_LOADING I post a message on my message queue (synchronization method I've used, PostMessage win32 API) in order to reload again with same API sp_session_load. As soon as it returns SP_ERROR_OK I use the sp_session_play and the music_delivery starts immediately, with correct frames.
I don't know why at the end of track the libspotify runtime then start sending zero padded frames, instead of calling end_of_track callback.
In other conditions it works perfectly: I've used the sp_track obtained from a album browse, so the track is fully loaded at the moment I load to the current session for playing: with this track, it works fine with end_of_track called correctly. In the case with padding error, I search the track using its Spotify URI and got the results; in this case the track metadata are not still ready (at the play attempt) so I used that kind of "polling" on sp_session_load with PostMessage.
Can anybody help me?
I ran into the same problem and I think the issue was that I was consuming the data too fast without giving other threads time to do any work since I was spending all of my time in the music_delivery callback. I found that if I add some throttling and notify the main thread that it can wake up to do some processing, the extra zeros at the end of track is reduced to one delivery of 22,050 frames (or 500ms at 44.1kHz).
Here is an example of what I added to my callback, heavily borrowed from the jukebox.c example provided with the SDK:
/* Buffer 1 second of data, then notify the main thread to do some processing */
if (g_throttle > format->sample_rate) {
pthread_mutex_lock(&g_notify_mutex);
g_notify_do = 1;
pthread_cond_signal(&g_notify_cond);
pthread_mutex_unlock(&g_notify_mutex);
// Reset the throttle counter
g_throttle = 0;
return 0;
}
As I said, there was still 22,050 frames of zeros delivered before the track stopped, but I believe libspotify may purposely do this to ensure that the duration calculated by the number of frames received (song_duration_ms = total_frames_delivered / sample_rate * 1000) is greater than or equal to the duration reported by sp_track_duration. In my case, the track I was trying to stream was 172,000ms in duration, without the extra padding the duration calculated is 171,796ms, but with the padding it was 172,296ms.
Hope this helps.
I have problem with setTimeout.
In all major browsers it works fine but not in IE...
I'm creating a facebook app- puzzle. When player press Start button, the timer starts count his time of playing one game.
At the beginning I used setInterval to increase timer but with cooperate of facebook scripts it delayed about 2 seconds at the end of game. Then I found on stackoverflow trick to increase accuracy of timer: setInterval timing slowly drifts away from staying accurate
And again- without facebook it worked fine, no delays were shown. With facebook it still has delays.
Now to condensate info that might interest You:
When user clicks Start then I create new Date as startTime.
When user ends game script creates finalTime new Date, then substract finalTime - startTime.
In code there is setTimeout:
(...)
f : function() {
var sec_time = Math.floor((puzzle.nextAt - puzzle.startTime)/1000);
$('.timer').html(sec_time);
if (!puzzle.startTime) {
puzzle.startTime = new Date().getTime();
puzzle.nextAt = puzzle.startTime;
$('.timer').html('0');
}
puzzle.nextAt += 100;
puzzle.to = setTimeout(puzzle.f, puzzle.nextAt - new Date().getTime());
}
(...)
when user place on correct place last puzzle piece then I call clearTimeout(puzzle.to);
I have now 2 issues:
not accurate time, in IE it can be even 7 second difference!
in IE during game it works only when user have mousedown... :/
To drag puzzles I use jQuery drag & drop plugin.
At least very helpful info will be how to achieve accurate timer.
You should put your scripts in jQuery's ready function and not at the bottom of the page, as the Facebook SDK is loaded asynchronously and may impact timed executions if they're initiated at the bottom of the page.
As for timing, you're gonna see inaccuracy of between 15ms and 45ms in IE7 depending on other JS executions on the page. Your 100ms timeout will drift badly because of this. Better to record a start time and build a timer with a higher polling frequency than needed and do a comparison between start time and 'now' in each cycle to determine what to do next.