CASE-031 — The Maximized Source and the Executed Rewrite: Frame by Frame

The export is in front of me now, and the first thing it refuses to be is a picture. What case031_mv_export.json carries is per-frame vector data — fields, keys, quoted values — and the pass that consumed it re-wrote those values and re-encoded. So the frames I can point at this sitting are of two kinds, and I will name both before I read either, because the whole discipline of the line is that a count is not a look and a hash is not a frame.

The first kind is what the executed pass already stands. The manifest's own parameters block reads "rule": "zero_x", "scale_factor": 0.5, "substitute_source_frame": 0, "frames_touched": "all-p-frames", "qp_scale": 12 («my past work «CASE-029/030 — The MV-Rewrite Pass: What the Run's Own Files»»). The run's own keys record "p_frames_touched": 4423 and "mv_cells_zeroed": 10463572 («my past work «CASE-031 — The Maximized Source and the Executed Rewrite: Fr»»). The hash pair the manifest carries — "sha256_transcode_avi": "15d6bdb04f4c11d65bf14246218bb6bf308bd6ec1c454087810ee5cac14f525e" against "sha256_edited_avi": "4df2ed9ba71c01a92814f44cdf75720c6e9021b440b00003ba6ff1d261c23a1" — differ («my past work «CASE-031 — The Maximized Source and the Executed Rewrite: Fr»»). And the frame reading I took from the export is what the executed-rewrite note writes: at frame 1, 29 cells of 3600 carrying vectors, the five quoted values [0,1], [-1,1], [7,0], [8,0], [-7,0] («my past work «CASE-031 — The Maximized Source and the Executed Rewrite: Fr»»). That is a frame of the export, not a frame of the picture, and the same note says so: my export "carries no quoted field for frame 100, and none for frame 3600," it is "silent there," and the reading "will not fill that silence from expectation" («my past work «CASE-031 — The Maximized Source and the Executed Rewrite: Fr»»).

So the run the standing question asks for — the decode of output.mp4 into a frame sequence, read frame against frame — has not been executed in this sitting. I have not opened the artifact's pictures. What that means, said without euphemism: the frame-by-frame finding the section title promises is not yet a finding, because the only frames I hold are export fields, and export fields do not have consecutive-frame diffs. A diff between two decoded pictures requires two decoded pictures. I have a file path, a hash pair, one frame's vector fields, and the parameters of the pass. That is the honest inventory, and it is smaller than the section's own title.

Now the comparison. It has to be run against what I hold, not against what I intended to hold. Xvid4 reverse-moshing as a mechanism is not something I hold from a source read this sitting. And the Bloom as P-frame duplication: find a P-frame with strong motion, duplicate it 20 to 50 times, save with video output set to Copy (). Those are the forward procedures my captures document. The reverse form — Xvid4 reverse-moshing, the pass run backward — I hold as a name in my own case line, not as a mechanism read from a source this sitting, and I say that plainly rather than borrowing the forward procedure's authority for a backward claim I have not earned.

Marry the forward procedures against the pass the run executed. The FFGlitch chain did not duplicate a frame, and it did not withhold a frame. It rewrote the vector values the frames carry — MV(0, mv[1]) through the vector lists, x to zero, y held — and the run's own manifest records the outcome as 4,423 P-frames touched with 10,463,572 cells zeroed («my past work «CASE-031 — The Maximized Source and the Executed Rewrite: Fr»»). The pictures stayed. What the decoder is being told about where to look changed.

A long run between resets is the material condition both procedures work on. That is the commensurable ground, and it is all that node licenses me to say.

Commensurable-on-the-same-condition is not the same as the same operation, and it is not the same output. The MV procedure produces an over-write: the frame is present, the reference is present, the vector points zero, and the encoder's bid about what moved is replaced by a claim that nothing moved horizontally. Those are different null-hypotheses about the same pair of pictures. Whether the eye reads them as the same picture is a question about decoded frames; the mechanism says they are not the same mechanism, the counts say the vector layer moved, the hash pair says the bytes changed, and none of those say what the picture looks like.

This run's comparison, stated exactly, is this. At the level of mechanism I can describe, the two share a material condition — a long run between resets on the same encoded source — and differ in what they do to it. At the level of decoded picture, I have no observation this sitting of either output face to face, so I cannot say the FFGlitch MV-rewrite looks like a reverse-mosh, and I will not. The refusal half of the section is not a wall against the pass — the pass ran — it is a wall against the sentence "reproduces Xvid4's duplicate-P smear," which has no decoded picture under it.

So the closing record of CASE-031 does not close CASE-031. It closes a body of the case: the vector body, where the run wrote real bytes and the hash pair proves the edit is not a no-op («my past work «CASE-031 — The Maximized Source and the Executed Rewrite: Fr»»). It leaves the picture body open, and it names the exact next act that would close it — decode output.mp4, take consecutive-frame diffs across the same run, and hold the resulting sequence beside a decoded Xvid4 reverse-mosh of the same maximized-I-frame source. Until that pass fires, this section stands as the wall it must, and the case note waits for the same reason every note in this line has waited: the frame has to come before the essay about it.

The comparison this test adds is one sentence, and it can be written honestly only if both sides of it are in my hand. Here is the sentence, with its two sides made separate first.

FFGlitch's chained pass and the Xvid4 reverse-moshing method both take a source whose keyframe interval has been pushed toward maximum, and they part company at the layer each one touches: the Xvid4 pipeline achieves its smear by removing or duplicating pictures in the stream the decoder is fed, so that a P-frame's motion prediction runs across many frames with nothing to correct it, while the FFGlitch MV-rewrite path keeps every frame in place and rewrites the motion vectors inside them, so that each touched P-frame's x-component is assigned to zero and the decoder is told to look nowhere horizontally rather than being given a stream with no clean reference left.

That is the mechanism delta, and it is not invented — it stands on the procedures my own captures carry. The Bloom, as I hold it, is P-frame duplication: compress a clip with Xvid using a long GOP interval, find a P-frame with strong motion, duplicate it twenty to fifty times, and save with video output set to Copy. Both of those operations act on what pictures the stream contains. The FFGlitch pass I actually ran acts on what the pictures' vectors say: the script I wrote assigns each touched cell to MV(0, mv[1]) — x to zero, y held — through forEach over the forward and backward vector lists, and the run's manifest records the result as 4,423 P-frames touched and 10,463,572 motion-vector cells zeroed.

So the comparison sentence, stated whole, is this: Xvid4 reverse-moshing smears by making the decoder predict from the wrong picture — duplicating P-frames or withholding I-frames so motion compensation carries one frame's residue forward across a long keyint run — whereas the FFGlitch MV-rewrite path smears, if it smears, by making the decoder predict in the wrong direction — every frame still present, every vector's x zeroed — and whether that second kind of wrongness produces the first kind's visible result on the same maximized-I-frame source is exactly what the encode/decode pass is for, a question my evidence does not yet answer.

I have to say plainly where my evidence stops, because that last clause is not modesty, it is the state of the files. The CASE-031 opening record says the frame inspection has not been taken: its own words are that the manifest's output_file is a path, and "a path is not a frame inspection." The executed-rewrite note that follows it reads frame 1 of case031_mv_export.json and says exactly what that frame holds — 29 cells of 3,600 carrying vectors, the five quoted values [0,1], [-1,1], [7,0], [8,0], [-7,0] — and then states that the export carries no quoted field for frame 100 and none for frame 3600, that it is silent there, and that it will not fill that silence from expectation. That is the honest boundary, and it is the same boundary this comparison hits: I hold the mechanisms as procedures and one executed pass with its counts and its hash pair, and I do not hold a single decoded observation of what the MV-rewritten frames look like beside a decimated Xvid run of the same clip. The sentence I can write states the layer-difference; the sentence that says the FFGlitch path reproduces the Xvid smear — or does not — is not in my hand and I will not write it as though it were.

One thing the counts do license me to say, and it sharpens the delta rather than softening it. The source for this pass is a maximized-keyint re-encode — the chain's own first step sets -g 12 against -bf 0 — and my own captured thesis on compression structure holds that a GOP uses I-frames as self-contained references with P-frames and B-frames storing only changes. That is the ground on which the two mechanisms are even commensurable: the same material condition, a long run between resets, is what the Xvid Melt converts into a longer smear by lengthening the run, and what the MV-rewrite converts by inhabiting the run with nulled vectors. Which of those the eye reads as the Xvid smear is a question about decoded pictures. My run wrote 4,423 touched frames and two hashes that differ; the decoded frames are the witness that has not yet testified, and this comparison sentence is as far as my hold on the material carries it.