If you moved the ‘whole folder’ (i.e. Funscript folder with the ‘use case’ folders still under it), then you are right, rerunning the installation will not update “–FSTB-PrepareVideoForOFS.1.0.bat” (because you might have made some changes to the script that I wouldn’t want to override). I didn’t think of that.
I only thought of the scenario where you put Funscript folder somewhere, ran the installation, and then, move only the ‘use-case’ folder somewhere else (ex. “FSTB-PrepareVideoForOFS”). In that case, rerunning the installation would recreate the whole “FSTB-PrepareVideoForOFS” folder, including the batch file, from scratch.
Anyway, I’m glad you managed to fix it.
Not sure what happened there. “*.mvs-visual.mp4.temp.mp4” is the temporary file name (yes, it’s a bit weird). In theory, you could have that state if the application was killed or crashed after creating “.mvs-p-frames.mp4” but before finishing creating the .mvs-visual.mp4 file.
I don’t think messing with the OFS extension was needed in your case but no harm was done by doing it.
Unfortunately, I don’t have best practices for that. You are describing a somehow complex movement. The plugin is mostly able to follow movement in a single direction (12 different angles, like a clock). You’ll have to see which option gives the best result in your particular case.
Nope, it’s only green arrows.
Thin black/white arrows (depending on the background color) are generated during the file preparation (i.e. .mvs and mvs-visual.mp4) and are ‘baked’ into the image. This is why we always see them when working in OFS. They represent the motion compared to the last frame, nothing more. They can be useful when scripting manually since you might see a frame where there aren’t many long arrows, which means, it’s probably the point where the girl is changing direction.
Fat (green) arrows are only shown in the plugin UI. In that case, the plugin analyzed all the video-motion-sensors (i.e. the thin black arrow) of all frames from the “stroke points” you provided. It determined which video-motion-sensors angle ‘agreed’ most often with your strokes (ex. stroke going up when the motion sensor was going to 4 o’clock, stroke going down when motion going in the opposite direction, 10 o’clock) and show fat green arrows to represent them (if they aren’t filtered by the different settings: Activity/Quality/Min%).
They can be moved to another folder. That’s what I do.
Humm, ok, I got it too and I’m pretty sure what it is (i.e. saved the .lua file as UTF-8 in this version and OFS doesn’t seem to like it) … I’ll make a new version.
This is great man unfortunately, the process for preparing the video for the plugin is CPU heavy. My old CPU can barely handle the load, Is that normal?
Yes, it’s normal since the preparation involves doing 2 re-encoding of the video, using the CPU. You could try reducing --ffmpegfilterHeight=2048 to a smaller value (ex. 1024) to reduce the preparation time.
I’m slowly working on a new version that will use a custom version of ffmpeg, instead of doing the work ‘outside’ of ffmpeg. This would reduce the number of re-encoding to 1 (or 0 if the .mvs-visual.mp4 is not generated), and give more options for speed up, without lowering the quality of the ‘motion vector’ part (ex. do the motion vector on 2048x2048 images but create a re-encoded 1024x1024 .mvs-visual.mp4 video).
