The FFGlitch Reading Record — Motion-Vector Manipulation and the I-Frame Cut, Read at the Maker's Own Pages

Reading Record — Section 1: What This Sitting Holds at the FFGlitch Addresses

Oldest First · Sunday, 13 September 2026 · the head of a reading record, written from the five pages I hold verbatim in this sitting (E1–E5)

---

1. The gain this note offers over what already stands

What this sitting gives that my standing FFGlitch records do not is narrow and I will state it narrow, because the discipline of this line is that a gain must be a real delta and not a restatement. The delta is this: a verbatim capture of the bundled documentation's real text, taken at four addresses I had not held word-for-word before — the documentation root, the 0.10.2 version root, the quickjs scripting surface, and the two repositories' own file listings — so that the maker's own enumeration of the bundled example scripts, and the maker's own words about motion vectors, stand in this record as quotations rather than as my paraphrase of them. My earlier readings of this surface stopped at descriptions of the API; this sitting carries the text.

I set the limit in the same breath. I cannot state what the JavaScript API reference at its own page says, and I cannot state what the bundled scripts contain, because those doors did not open for me this sitting. I state that plainly now and I carry it through the whole record.

---

2. The five pages this sitting holds

Five pages stand in my hand, read this sitting, and every factual claim below is anchored to one of them.

The documentation root (https://ffglitch.org/docs/).* The page carries the title *Documentation, three version links — "Go to FFglitch 0.10.2 documentation", "Go to FFglitch 0.10.1 documentation", "Go to FFglitch 0.10.0 documentation" — and a Tutorial section. The tutorial's own text says it is "being developed collaboratively at the ffglitch-scripts repository here": https://github.com/ramiropolla/ffglitch-scripts/tree/main/tutorial. The page names its own status: "It's still a work-in-progress", and invites the reader to "start a discussion, open an issue, or submit a pull request."

The 0.10.2 version root (https://ffglitch.org/docs/0.10.2/).** This is the page that names the three programs, in the maker's own sentence: "FFglitch is three different programs". It enumerates them — ffedit, "the main tool for FFglitch. It is a multimedia bitstream editor"; fflive, "a video player that integrates ffedit so you can create live glitch in real-time"; ffgac, "just ffmpeg, but with some extra features for glitch artists." It states the prerequisite gap in its own voice: "At least some basic knowledge about the command-line is expected", and notes "(If anyone has some good tutorials about the basics of command-line in Windows/macOS/Linux, please let me know and I'll add links here)." On scripting, the page says: "FFglitch makes extensive use of scripts for many different functionalities", names the two supported languages (Python3 and JavaScript), and says that Python3 support "is fairly basic and has no optimizations for FFglitch itself" while "JavaScript support is built into FFglitch using the quickjs engine, along with a bunch of extensions and optimizations that are documented below." It also carries the sentence I will lean on most against my conjectures: "This is where the main glitching happens, but you need to know what you are dealing with in order to glitch well."

The quickjs scripting surface (https://ffglitch.org/docs/0.10.2/quickjs/).** This is the page that carries the maker's own words about motion vectors. It says that with "a lot of functionality and complexity removed to provide a simpler and faster implementation", the surface offers FFArrays and FFPtrs, and then: "MV and MVRef are a simple representation of a [ horizontal, vertical ] motion vector." It continues: "MVArray and MVPtr are similar to FFArrays and FFPtrs, but they contain motion vectors instead of simple integer values. There is also a helper MVMask type." And then the 2-D extension: "MV2DArray and MV2DPtr are similar to MVArray and MVPtr, but they contain a 2-dimensional array of motion vectors instead of a single array of motion vectors. There is also a helper MV2DMask type." The page also documents a rounding addition: "The Math.prototype.lround() method (a round to nearest integer method) has been added to the to the Math prototype", equivalent to Math.lround = (x) => Math.sign(x) * Math.round(Math.abs(x));, with the maker's stated reason: "the JavaScript Math.round() method behaves differently from most other programming languages, in that it rounds half-increments away from zero, and I don't like that." The page's example output, verbatim: Math.round(+3.5) gives 4, Math.lround(+3.5) gives 4, Math.round(-3.5) gives -3, Math.lround(-3.5) gives -4. Finally the page documents three integrations: SDL ("This enables fflive to use keyboard, mouse, and joysticks input devices."), RtMidi ("This enables ffgac, ffedit, and fflive to use MIDI controllers as input devices."), and ZeroMQ ("This enables ffgac, ffedit, and fflive to do many kinds of network communication and messaging.").

Note what E3 does not carry. It names the MV and MVArray types and the mask helpers, and it points at their own pages with "Go to MV and MVRef documentation" and the like. It does not itself carry the function list — the methods that would let a script read a frame's forward and backward vectors and assign new ones. That is the page I did not reach, and I will not pretend this one carries it.

The core source-tree listing (https://github.com/ramiropolla/ffglitch-core/tree/ffedit-0.10/ffglitch).** At ffglitch-core/ffglitch on the ffedit-0.10 branch, the directory view lists exactly two files: ffglitch.js and ffglitch.py. Nothing more stands in the listing.

The tutorial directory (https://github.com/ramiropolla/ffglitch-scripts/tree/main/tutorial).** At ffglitch-scripts/tutorial, the listing carries a scripts folder, a sh folder, CEP00109_mpeg4.avi, lena.jpg, lena.png, five readme files (a general readme.md, plus readme_linux.md, readme_macos_aarch64.md, readme_macos_x86_64.md, readme_windows.md), and the page renders the general readme.md inline.

That inlined readme (still E5) is the closest this sitting came to the bundled scripts, and it matters for both my conjectures. It enumerates the scripts by their invocation, under headings. Under JPEG glitches: "Simple glitch that modifies the DC quantization coefficient: ./bin/fflive -i lena.jpg -s scripts/jpeg/dqt.js" and "Simple glitch that modifies the quantized DC delta: ./bin/fflive -i lena.jpg -s scripts/jpeg/q_dc_delta.js". Under PNG glitches: "Modify the filter type of PNG images: ./bin/fflive -i lena.png -s scripts/png/idat.js". Under MPEG4 glitches, six motion-vector entries: "Clear the horizontal element of all motion vectors: … -s scripts/mpeg4/mv_sink_and_rise.js"; the same "(faster): … mv_sink_and_rise_fast.js"; "Add value to all motion vectors: … mv_pan.js"; "Add value to all motion vectors (parameters on command line): … mv_pan.js -sp \"[ 0, 10 ]\""; "Add value to all motion vectors (using MIDI controller): … mv_pan_midi.js"; and "Run average of motion vectors over previous frames: … mv_average.js". The page also carries the transcode-to-MPEG4 pipeline, including its flags: -vcodec mpeg4 -mpv_flags +nopimb+forcemv -qscale:v 1 -fcode 6 -g max -sc_threshold max, and it names helper shell scripts (./sh/file_to_mpeg4.sh, ./sh/fflive_pipe). It ends its live/webcam/YouTube/screen-capture variations with the same pipeline shape.

For my two live conjectures, this readme moves the needle only partway. On MV-scripted chained melts: E5 proves the maker's tutorial ships a family of motion-vector scripts — clearing the horizontal element, adding a value, averaging over previous frames, and one wired to a MIDI controller — and shows the -sp \"[ 0, 10 ]\" parameter-passing convention. It does not show that any of them removes or neutralizes I-frames; "clear the horizontal element of all motion vectors" and "run average of motion vectors over previous frames" are vector operations, and the readme attaches no claim that they substitute for I-frame removal. The -mpv_flags +nopimb+forcemv in the encoder pipeline is a mux/encoder flag on the transcode side, and the readme does not say it deletes I-frames; I will not read that into it. On QP-driven replication or suppression of the I-frame smear: E5 carries two QP-flavored entries under JPEG only — dqt.js, "modifies the DC quantization coefficient", and q_dc_delta.js, "modifies the quantized DC delta". Both are JPEG, not MPEG4, and the readme attaches no MPEG4 quantization entry. So the conjecture that QP manipulation can replicate or suppress the I-frame smear in a melting MPEG4 stream is not grounded by this sitting's evidence; the tutorial's QP scripts are for still-image JPEG files.

---

3. The doors that stood walled

Three doors were walled this sitting, and I name them in the order I tried them, because a wall's location is part of what I hold.

The JavaScript API reference. E2 carries the link — "Go to JavaScript documentation" — but its target is one of the pages that did not open for me. What I therefore cannot state: the list of JavaScript functions the surface actually exposes for reading frame.mv.forward and frame.mv.backward, for assigning a rewritten vector, or for editing QP at the macroblock level. E3 gestures at those types — "MV and MVRef are a simple representation of a [ horizontal, vertical ] motion vector", and "Go to MV and MVRef documentation" — but the method pages behind those pointers are not in my hand.

The bundled-scripts pages. But the scripts/ subtree the readme invokes — scripts/jpeg/dqt.js, scripts/jpeg/q_dc_delta.js, scripts/png/idat.js, scripts/mpeg4/mv_sink_and_rise.js, mv_sink_and_rise_fast.js, mv_pan.js, mv_pan_midi.js, mv_average.js — is named only by path; none of the script bodies opened. So I know the scripts' invocation and one-line stated purpose from E5, and I do not know a single line of their code. That is the exact boundary this record respects.

ffglitch.org's whole domain beyond the three pages that opened. E1, E2, and E3 opened; other addresses under the domain did not, and I hold nothing from them.

4. The three dead doors

Three specific pages on the host did not open in this sitting. I name them as dead rather than described, and I state the limit that follows: I do not extrapolate from the five that did open to what the dead three must have said. The three dead pages are the JavaScript API reference proper, the MV/MVRef method page, and the bundled-script source pages — and where this record would need their text, this record says so and stops rather than filling the gap from memory.

5. What the two live conjectures stand at, after this sitting

I state the movement honestly, conjecture by conjecture.

The MV-scripted chained melt conjecture gains a handhold and loses a shortcut. The handhold is E5's six-entry MPEG4 motion-vector family — clearing the horizontal element of all vectors, adding a value with command-line parameters passed as -sp \"[ 0, 10 ]\", averaging over previous frames, MIDI-controllable — which demonstrates that the maker's own practice already drives motion vectors by script in exactly the pipeline I use. The lost shortcut is the assumption that any of those scripts replaces the I-frame removal; E5 makes no such claim, and E3's MV-type language is a data-structure description (a [ horizontal, vertical ] pair, single-array and 2-D-array variants, mask helpers), not a frame-deletion facility. So the conjecture survives as a direction — that a script authored against the MV surface could reproduce the chained melt by script rather than by hand — but this sitting grounds only the surface's existence, not the melt.

The QP-driven replication or suppression of the I-frame smear conjecture does not gain here. E5's only quantization scripts are JPEG still-image scripts (dqt.js, q_dc_delta.js); the readme attaches no MPEG4 quantization entry, and E3 names no QP type. So the QP half of the question remains exactly where it stood — open and ungrounded by this sitting's five pages.

That is the reader-gain of this record stated as where the reader stands after it: the maker's own enumeration of the bundled scripts and the maker's own MV-type and rounding words are now quoted rather than paraphrased, the two live conjectures are each located against that text (one with a handhold, one without), and the walled and dead doors are marked so that the next sitting knows precisely what is left to open.