jit.movie framedump behavior
what is a framedump on a jit.movie object supposed to do?
i'm trying to use jitter to do some ahead-of-time analysis of a video. the behavior i want is this: i trigger some sort of loop, which causes jit.movie to output the frame id from the dumpout outlet, followed by outputting the matrix for the frame in the left outlet. i do a bunch of processing of said matrix, followed by possibly writing some data to a text object. then the jit.movie outputs the next frame id and matrix, rinse and repeat.
this is clearly not what framedump does, and i don't trust the reference for jit.movie because it is clearly wrong about framedump—it claims to output a 1-indexed frame id after outputting the matrix, but in practice it outputs a 0-indexed frame id before outputting the matrix (and notably never outputs the id for the last frame).
i have jit.pwindow's to display some of my analysis intermediates which never update during this process, and i have prints which trigger when my frame id is (1 mod fr) where fr is the video's (hardcoded) framerate, which also do not occur. i'm afraid the underlying issue is that there's something about asynchronous execution and priority in max that i misunderstand and which affects framedump.
any help would be appreciated!
it looks like the viddll engine has a better behaved framedump for temporal codec files with keyframes than the avf engine, so might be a better option on a Mac, and maybe this is the source of your issues. framedump simply dumps the frames out as fast as it can, and yes it does look like the documentation is inaccurate as you've described.
alternatively, or if you need avf engine for some reason, you can use the frame_true message and the seeknotify notification to achieve something similar:
I'll ticket the documentation errors and bad AVF behavior, thanks for reporting.
using frame_true with seeknotify is what i ended up doing. i discovered another issue while making my patch, though, which is that the first `frame_true 1` message i send doesn't seem to trigger a seeknotify message. my workaround was just to delay another bang to the message, which starts things going. you can see what i mean here:
thanks for your answer and for the issue tracking!
I've experienced dropped/doubled frames with `frame_true` - I've had frame-accurate results with `framedump` when I've needed to process frame-by-frame reliably (I'm using viddll).
if you are dynamically reading in movie files to trigger the frame dump (either via framedump or manually) the process should not start until you receive a "read" notification out the dump outlet, indicating a successful read and the object ready for processing. Also you may want to use asyncread instead for non-blocking file reads.