Difficulty understanding and implementing 'gettime' and 'frame n' in Jitter
Hi all,
I've searched the forum and help files for a few hours and haven't been able to find a solution to my problem.
I am using jit.xfade, with multiple looping videos. I would like to cross dissolve from one video to the next at the same timecode point in each video. E.g. Video A is currently at frame 32 at the moment the xfade is triggered. I want video B to start playing at frame 32.
I've seen posts on gettime to query, and frame n (where n is the frame number you want to access), to initiate playback at a particular frame, but I'm basically just not understanding these concepts well.
I've tested repeatedly and gettime seems to report inconsistently, and therefore I can't use it as a starting point to do some simple math to attain the current video frame. I've been testing out a variety of videos and some start at time 0 (with the 'gettime' + 'route time' combo), while others start much much later. As I understand it, when the video is at the very beginning, no matter what kind of video it is, it should always report 0 for 'route time'.
Secondly, 'frame n' seems finicky as well. In trying to access frame 3, for example, when I look at the 'route time' it reports 0 (and it should be something more like 75). I'm guessing this has to do with export settings. This is my hunch because when I re-exported the countdown.mov file while troubleshooting (which I exported as QuickTime, H.264, 720p 24fps), the newly exported file was reporting these oddities. Of course I will want to use my own footage and not countdown.mov ultimately, so I'm not sure how to solve this particular issue either.
Lastly, why is it that in this example below, a video that has a frame rate of 24fps, and is 10 seconds long (and should therefore be 24x10=240 frames) has a duration of 6000? You need to divide 6000 by 25 in order to get the total number of frames (240), where I feel like you should have to divide the duration by the frame rate (6000 / 24). I'm clearly missing something here, I just don't know what.
Thanks for any help you can offer!
Have you looked at the old Jitter Appendix A "A QuickTime Confidential" at all? It may assist you in making sense of the difference between timescales and frames, at the very least....
hi Tori.
video playback has gotten slightly more complicated in Jitter since the old days of pre Max 7 and quicktime. but we also had to support legacy quicktime behavior, which makes things still more complicated.
one misconception it seems you have, is that duration is not in seconds, but in something called "time units". the duration of a movie is equal to the length in seconds multiplied with the "timescale" attribute.
fortunately with Max 7, you no longer have to worry about that, and you can simply use the position attribute to calculate your current frame. position is a floating point value that goes from 0 to 1 (0 = start, 1 = end of the movie). you can multiply this with your framecount value to get the current frame. you also have to round up (by adding 0.5) if you want an accurate integer value.
the last wrinkle that may be causing your problems is that if you are on Mac, seeking is asynchronous. what this means is there is a slight delay from when you request a seek in the file (e.g. with the frame message), and when the movie playhead actually arrives at that time. the jit.movie object will output a notification, "seeknotify", out the dump outlet when it has arrived at the previous seek request.
search the forum and reference browser for "seeknotify" for more info.
Hi Max, thanks for your response. I read the link you offered as well as the Max 7 version of Appendix A "A QuickTime Confidential" which removes references to the old jit.qt.movie:
https://docs.cycling74.com/max7/tutorials/jitterchapter99_appendixa
The two documents were extremely helpful in demystifying some of my questions!
Hi Rob, thanks also for your help. Your explanation and patch are very clear, and help immensely. I searched the forums for seeknotify and found this useful piece of code posted by Ben Bracken:
I'll take the feedback you two have given me and see if I can apply it to my patch.
Thanks so much for your help!