There is definitely something wrong. You seem to end up with the filename “-1.mvs-p-frames.mp4” passed to ffmpeg, which is then interpreted as an argument by ffmpeg because it starts with a “-”.
I just tested it.
The problem is that you need quotes around the ffmpegfilter argument because it contains spaces. Like this:
I’ve been playing with various optical flow codes the past month or so, RAFT seems to generate the best outputs but it’s slow. And that’s after downsampling one half of each frame to 512x512. Downsampled to a consistent resolution followed by optical flow is my current choice of input image format. Have you found better? OpenCV methods seem pretty slow as well with inferior outputs.
Thanks for that, after a bit of trial and error I got it right with my own video!
But the whole thing only works with one body moving, it doesn’t work with two bodies moving in different directions, or is there a trick?
First off, thanks so much for making this! I’m getting into scripting and this seems to be an indispensable tool in expediting the creation process. Now that I’ve got cooking I can see even without the automated insertion that the visual indicators can help you “see the future” on where a stroke is going to begin or end. That in turn helps you to see where to place the markers to get the automation insertion to do much of the work for you after that.
Something else I didn’t realize is that the min/max/center pos and other options adjust the insertion on the fly. I thought I was going to need to adjust this before the automatic insertion. Very, very useful.
That said I wanted to give some feedback on some stumbling blocks I ran into getting things started. Towards the top of the instructions it’s mentioned:
Note: If you move the “FunscriptToolbox” folder in the future, you will have to re-run --FSTB-Installation.bat to update the plugins and ‘use-case’ scripts.
This isn’t the full story and after installing it, I wanted to move it to a different location, but ran into the issue memeweaver encountered with FunscriptToolbox not being recognized as an internal command as the path in --FSTB-PrepareVideoForOFS.1.0.bat did not get updated even though I re-ran the batch script as instructed. (Perhaps because I moved it into the ProgramFiles/OpenFunscripter directory and didn’t have administrative privileges?
I patched this up and got rolling however I ran into another issue where after running the batch file I did not have the *.mvs-visual.mp4 file. Instead I had *.mvs-p-frames.mp4 and *.mvs-visual.mp4.temp.mp4. These as you may expect did not work correctly.
So I decided to move it again and do a “complete uninstall/reinstall”. With this I deleted where I had extracted this MotionVectors plugin saved to (C:/ProgramFiles/OpenFunscripter/FunscriptToolbox) as well as %appdata%/Roaming/OFS/OFS3_data/extensions/FunscriptToolBox.MotionVectors.
After this I re-extracted to a non-admin place, and followed install instructions. Everything seems to be working.
My lingering question is if I missed anything in “completly uninstalling” the plugin before re-installing it; in case I run into any more issues. Also just wanted to document my troubles if anyone else runs into them.
Thanks for creating this. I’m finding it helpful, and I’m trying to improve my technique with the tool.
I’m looking for a “best practices” way of handling a particular kind of scene:
The girl is rubbing her pussy in a circular motion, so at the top all of the vectors are pointing right (3 o’clock), down as she moves her hand down (6 o’clock), left at the bottom (9 o’clock) , then up again as her fingers move up (12 o’clock), finally turning to the right (3 o’clock) .
In setting up the stroke points in OFS to prime the tool for the best outcome, is it better to ‘lead’ the top and bottom point so that they are still on the up/down vectors, or at the top and bottom of the swing, where the motion is 3/9 o’clock?
Also: Some of us are red/green colorblind, so if there’s not-green arrows out there (not the black and white arrows), I can’t tell.
When you’re adjusting the Activity/Quality/Min sliders, and the vectors on the part of the video you’re interested in are going the correct direction, but thin black arrows, and not the fat (green) arrows, what does that mean?
Do the mpg files have to be in the .\FunscriptToolbox\FSTB-PrepareVideoForOFS folder once you’ve prepped them, or can they be moved to a project folder to be opened with OFS?
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).
