FFglitch 0.9.4 has been released.
The main change in this version is the addition of
support. This way you don’t need to use the old three-step method of
apply for your Python scripts anymore. It can all
be done in one go, just like it was already possible with
since version 0.9.1.
For example, the
Simple motion vector tutorial
python3 would be:
def glitch_frame(frame): # bail out if we have no motion vectors if not "mv" in frame: return # bail out if we have no forward motion vectors if not "forward" in frame["mv"]: return fwd_mvs = frame["mv"]["forward"] # loop through all rows for row in fwd_mvs: # loop through all macroblocks for mv in row: # clear horizontal element of all motion vectors # THIS IS WHERE THE MAGIC HAPPENS mv = 0; # this sets the horizontal motion vector to zero # mv = 0; # you could also change the vertical motion vector
$ ./ffedit -i temp_file.mpg -f mv -s mv_sink_and_rise.py -o glitched_file.mpg
NOTE: You have to install Python3 yourself! Get it from their website: https://www.python.org/downloads/.
Script video filter
Python, so that you can edit the pixels of a video programmatically.
You can chain the filter on top of an existing video or create a video
For example, create this file named
def filter(args): data = args["data"] # planes are [ Y, U, V ] for p, plane in enumerate(data): # skip plane Y if p == 0: continue # for planes U and V, draw a color plane for i, row in enumerate(plane): for j in range(len(row)): if p == 1: row[j] = j+j else: row[j] = 254-(i+i)
and then run it on top of the
testsrc2 video source from
$ ffgac -f lavfi -i "testsrc2=duration=10:size=256x256" -vf script="py=uv.py" -q 0 -y testsrc2_uv.mp4
and you’ll end up with this nice video:
Motion Vector Delta Feature
Motion vectors values are composed of a
prediction part and a
delta part, which is the value that is written to the bitstream.
A new feature named
"mv_delta" has been added to ffedit, which
allows you to fiddle with only those
delta values for both
There is no example for this feature for now. This is left as an exercise for the reader.
Motion Vector Overflow
There is now greater control on how
ffedit should behave when it
encounters an overflow in either the
"mv" or the
Three more values are exported, namely
The first two are for information purposes only and allow you to calculate
the min and max values for your motion vectors if you wish.
MPEG-2 the values go from
MPEG-4 the values go from
which, for an
1, would range from
[-16, 15] for
[-32, 31] for
MPEG-4 (keep in mind that those are half-pel values).
"overflow" field tells
ffedit how to behave when it encounters
an overflow while transplicating a file. The four possible values are
frame["mv"]["overflow"] = "assert"; // quits ffedit on overflow frame["mv"]["overflow"] = "truncate"; // truncates values within range for given fcode frame["mv"]["overflow"] = "ignore"; // just ignore the overflow - same behaviour as versions before 0.9.4 frame["mv"]["overflow"] = "warn"; // ignore, like above, but also write a warning message - new default behaviour
I’m too lazy to write an example for now. This is also left as an exercise for the reader.
A new executable called
qjs.exe for Windows) has been added
to the release bundle, along with a new file
qjs is the
quickjs command-line interpreter. It can
be used to test your
ffglitch.js It works similarly to
ffglitch.py, but for
$ ./qjs ffglitch.js -i mv.json -s mv_sink_and_rise.js -o mv_glitched.json
- Speedup exporting of JSON data by up to 40%
- Speedup importing of JSON data by up to 80%
MPEG-4(works the same way as it did for
-dqtoption for non-mjpeg (broken in
- Updated quickjs to quickjs-2021-03-27
My build system has changed
I now have a mac mini running Mojave and I build the macos version there. If it doesn’t run on older versions of macos please let me know and I’ll try to figure out a way to fix it.
The linux build no longer uses musl, but is built on a CentOS 7 image, which should run correctly on most modern distros.
Get it in the Download page.