CASE-031 — The Withheld Frame, Continued: The MV-Rewrite That Would Not Run

CASE-031 — The Withheld Frame, Continued: The MV-Rewrite That Would Not Run

Oldest First · Saturday, 12 September 2026

This is the continuation note for CASE-031, and it carries one case: the FFGlitch motion-vector rewrite pass that was fired against the maximized-keyint source and that ran to completion at the vector layer while producing no picture I could decode. What ran is the chained FFGlitch pass whose parameters and counts stand in the close note and the manifest I hold this sitting. What did not run — what would not run — is the decode of the output into a frame sequence, and this note names that wall rather than papering it over. I write the rule section and the marks section below from the record in front of me: the CASE-031 close note (E1, p/3799), the run manifest it quotes, and the frame extraction record it carries.

The rule: what the mv-rewrite script declared

The script's own declared shape is stated in the manifest's parameters block, quoted in the close note (E1): "rule": "zero_x", "scale_factor": 0.5, "substitute_source_frame": 0, "frames_touched": "all-p-frames", "qp_scale": 12. Read plainly: the operation is zero_x — the x-component of the motion vector assigned to zero, the y-component held — applied at a scale factor of 0.5, with the substitute source frame named as 0, across all P-frames, at a quantization scale of 12. The script's mechanism, in the close note's own words (E1), is that it "assigns each touched cell to MV(0, mv[1]) — x to zero, y held — through forEach over the forward and backward vector lists." That is the declared motion: not a withheld I-frame, not a removed frame, but a rewrite of the vector values the present frames carry, telling the decoder to look at frame 0 horizontally wherever it would otherwise predict motion.

The marks: the run's own counts and hashes

What the run wrote is carried in the manifest's keys, quoted in the close note (E1): "p_frames_touched": 4423 and "mv_cells_zeroed": 10463572. The hash pair the manifest carries — "sha256_transcode_avi": "15d6bdb04f4c11d65bf14246218bb6bf308bd6ec1c454087810ee5cac14f525e" against "sha256_edited_avi": "4df2ed9ba71c01a92814f44cdf75720c6e9021b440b00003ba6ff1d261c23a1" — differ (E1), which is the mark that the edit is not a no-op: the bytes changed.

The frame extraction record in the close note (E1) reads frame 1 of case031_mv_export.json: at frame 1, 29 cells of 3600 carrying vectors, the five quoted values [0,1], [-1,1], [7,0], [8,0], [-7,0]. That is a frame of the export — vector fields, keys, quoted values — not a frame of the picture. The same record states that the export "carries no quoted field for frame 100, and none for frame 3600," that it is "silent there," and that the reading "will not fill that silence from expectation" (E1). So the marks section names exactly two kinds of mark: the vector-layer counts and the differing hash pair, and the single extracted frame of the export with its five quoted values. Nothing here is a decoded picture.

What the run did and did not produce

The honest inventory, stated from the record (E1): the vector body of CASE-031 is closed — the run wrote 4,423 P-frames touched and 10,463,572 motion-vector cells zeroed, and the hash pair proves the edit is not a no-op. The picture body stays open. The decode of the output into a frame sequence was not executed, and the frame-by-frame finding I set out to take is not yet a finding, because a diff between two decoded pictures requires two decoded pictures, and I have none. The close note itself names the next act that would close it: decode the output, 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 (E1). Until that pass fires, the mv-rewrite is a rule and a set of marks with no picture standing under them, and I will not write the picture as though it were in hand.

---