One issue I'm getting in an old pd patch is that the video playback is going super fast.
Not only this is annoying to see but mostly it is out of sync with the corresponding audio.
All the videos in the library are matching frame size and rate.
I tried changing the gemwin framerate but it didn't work.
Bare in mind that this patch was up and running very well some 3 or 4 years ago.
Would the updated versions have anything to do with this?
Any ideas? suggestions?
video playback framerate wrong
@jbvidigal Hello ....... some codecs use variable bit rate and framerate nowadays for their compression algorithm,..... check with a tool like "MediaInfo" as the os will most likely be lying......
Sorry to but in if it is a video that you rendered yourself!
@whale-av the videos were compressed by me.
I'm OSX platform in different computers. Last time I used this patch was in 2013. The videos are all the same... everything is pretty much all the same. Only two things change: pd-extended version and OSX version as well as the computers!
This patch was up an running properly with the videos and their corresponding audio. Now it's not and I can't figure this one out.
If the gemwin is open the audio plays just right. If I open the gemwin, not only the audio jumps, although keeping the pitch/rate and the video plays jumping but with a much faster rate!
@jbvidigal Any chance you could post the patch (extended preferred as gem is not working well for me with vanilla 046.7 on windows)...... and the video (or a small cut if the file is huge).... but first... are the audio settings correct for the new computer (audio playback running well on it's own)?......
....... but then I would expect the video to stagger rather than running fast.
So also.... do you have two versions of Gem on the computer?...... confusion... wrong object versions being called?
But Gem uses the graphics card renderer to do the work....it just sends instructions.. so the problem could be there? You might need to upgrade/ downgrade the openGl as the xcode has probably been updated.
If the videos are mp4 or other variable frame-rate then you can fix that using http://www.squared5.com/
@jbvidigal I cannot see anything unusual...... and all videos seem to behave as expected under extended 0.43.4 with Gem 0.93.3 under windows7........ not what you wanted to hear I know. I can try splitting the audio out of a .mov file to double-check tomorrow...... but an .mp4 countdown clock plays correctly.
@whale-av I guess all I can try is to use 0.43.4 or similar.
The GEM window is stalling the whole system and I can't figure that one out! Do you think it can be the computer? I'm trying the patch on a "new" 2nd hand macmini and I know GEM sucks up a lot of juice. This mac mini is not optimised with SSD nor RAM maxed...
Also I figured the frame rate is being doubled (god know why!) which means I can't even half it as the videos are on 25fps, meaning half would not be an integer! So it's either slightly faster or slightly slower!!! Very annoying
@jbvidigal As far as I know 043.4 is the last version of Pd for which Gem was released fully working (not Alpha)..... so yes, I would give that a go and let [pix-film] run frame by frame.... [auto 1(.........(not try to force a frame-rate in the [gemhead]).
Any graphics card at all (since the 1980's) should be able to render the video at 25pfs, and it will be the graphics card doing the work, not Gem....... it should easily run a video. If you then have problems with audio sync you can control the video from the soundfile, but yyou would need to re-render the video at a constant frame-rate first (.avi or similar).......
That patch stores audio in ram, which reduces disk access, but limits the length of the video...... it can be solved...... just requires more work!
@whale-av can you say +/- the max possible length? the videos I'm working with are short samples, the longest one being 54' (+/- 1350frames)
Also I've been trying on another computer (macbookpro) with 0.43.4 and the issue remains! the video plays at double the speed! However, I tried the av-sync.pd patch you sent and it works just fine! I don't get it. The files used are the same, the gemwin is the rendering engine on both and working the same way... clearly there's something in the way that I can't figure out!
@jbvidigal No, I don't understand why either..... I will look harder at your patch when I can.
The length for [av-sync] is limited to 40 million samples (for a Pd array) which is about 907 seconds I think for 16-bit mono at 44.1KHz...... so about 15 minutes.
The patch forces the video frames to match the audio time...... so always in sync...... as the frame-rate is controlled by the audio!
I think my patch only loads the left track....... you will need to tell [soundfiler] that you want 2 channels..... and 2 arrays..........and create a right channel array and right channel [tabread4~] for a stereo version...
I am glad the patch works for you!.......
PS..... I might have found the error in your patch.......... in the video players you are sending a bang to the message [auto $1( through a toggle, and then sending another bang to it after a delay. The second bang turns it off!........ (because of the toggle)......
First bang message "auto 1"
Second bang message "auto 0"
I was away for a couple weeks, am now back on this!
I am trying to adapt your patch to mine. However there is this issue I'm finding...
I need to open all files, audio and video, in order to cache them so that when working they are ready to be triggered and not load as they are called.
To do that, on my patch I call them all sequentially when I load the patch. For each file I have a [pd ...] box loading each file with each one's path on a message box. However I can't seem to be able to do that with your method.
Any suggestions on I could do that?
PS - I used a message box starting with symbol following the path of the file to load the file I wanted and it worked... for now...
Now all I need to do is repeat this for all the files and see how that works
@jbvidigal Hello again......
Yes, you can load the audio ready to play...... it goes to the $0-soundfile table ready to be played from ram. The video though is played from disc, in sync with the audio. The video file cannot be "pre-loaded" as such......
I think the problem you have is that you are putting my patch (or yours probably) as a sub-patch [pd something] and so all of the $0's have the same value derived from the main patch.
You need to copy the contents of your [pd-something] into a new patch window and save that as "something.pd". Then in your main patch you retype your sub-patch objects as [something 1] for the first and [something 2] etc. (abstractions - not sub-patches) and then they will each have a different value for $0.
All that is of course a "maybe" as I have not seen your patch. Zip yours up without the media files if you still hit a brick wall, and we can all have a look and better let you know how to solve any problems.......