CASE-031 — The MV-Rewrite Run: What the Export Actually Says About the I-Frame and the Vectors

CASE-031 — The MV-Rewrite Run: What the Export Actually Says About the I-Frame and the Vectors

Oldest First · Sunday, 13 September 2026 · Section 1 of the resolution note · written from the export file and the two case works in my hand

---

1. The export's own fields, read plainly

The run I am describing is the FFGlitch motion-vector rewrite pass executed against the CASE-031 maximized-keyint source, and what I have in hand is not a recollection of that run but the export file it wrote and the notes that already stand beside it. I will state the machine's own fields before I interpret a single one of them, because the discipline of this case line is that the export's verbatim values are the witness and my reading of them is only argument.

The export file is case031_mv_export.json, standing in the output folder case031_mv_rewrite/ («/Users/zhouzhulin/Scintilla Builds/CASE-031/output/case031_mv_rewrite/case031_mv»). Its header records the tool and the subject in three quoted fields: "ffedit_version":"ffglitch-0.10.2", "filename":"case031_mv_transcode.avi", and "sha1sum":"6d9be4a3d720d21b24022b7442e2264fbd44d5ea" («/Users/zhouzhulin/Scintilla Builds/CASE-031/output/case031_mv_rewrite/case031_mv»). The features array carries a single entry, "mv" («/Users/zhouzhulin/Scintilla Builds/CASE-031/output/case031_mv_rewrite/case031_mv»), and the stream block declares "codec":"mpeg4" («/Users/zhouzhulin/Scintilla Builds/CASE-031/output/case031_mv_rewrite/case031_mv»). Those five fields say what ran, on what file, and that the hash the export carries for its own subject file is 6d9be4a3… — the export's fingerprint of the AVI it describes, not a picture and not a quality claim.

Then the frames. The export's frames array opens with a packet at "pkt_pos":5762, "pts":0, "dts":0 whose motion-vector block is empty — the JSON reads "mv":{ }, nothing between the braces («/Users/zhouzhulin/Scintilla Builds/CASE-031/output/case031_mv_rewrite/case031_mv»). The second packet stands at "pkt_pos":15800, "pts":1, "dts":1, and its "mv" block carries a "forward" list («/Users/zhouzhulin/Scintilla Builds/CASE-031/output/case031_mv_rewrite/case031_mv»). So the export draws its first boundary here, in its own bytes: the packet at pts 0 has no vectors to report, and the packet at pts 1 has forward vectors. That is the shape of a reference frame followed by a predictive frame in an encoder's output, and the export states the shape as data before I say what it means.

I want to be exact about the pts-1 block rather than summarize it, because "carries vectors" is the kind of phrase that can hide a lie. The "forward" list is a nested array of rows, and the overwhelming majority of its entries are null — the value the export writes where a cell holds no vector. Scattered through the rows are blocks of two-integer vectors: [0,1], [-1,1], [7,0], [8,0], [-7,0], then further down [-1,-1], [1,-5], [-2,0], [-1,0], [1,-1], [-1,-1] in one row; [8,0], [8,0], [-7,0], [2,0], [1,0], [0,-1] across the next rows; [1,0], [8,0], [8,0], [-7,0] in another; [-1,0], [8,0], [0,-1] in another; [0,-1], [0,7]; then [0,1] alone, then [0,1] and [0,1] again near the tail of what the export holds («/Users/zhouzhulin/Scintilla Builds/CASE-031/output/case031_mv_rewrite/case031_mv»). The empty cells are the majority; the populated cells are sparse and carry the integer pairs above. That is what the pts-1 frame's forward vector list literally contains, read from the file, and I will not round it to "a few vectors" when the export prints them one by one.

I have to state the boundary of this evidence as plainly as its content, because the section title I was given reaches further than the file does. The export in my hand is the executed-rewrite work's own output, and the executed-rewrite note already stands on record 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 («my past work «CASE-031 — The Maximized Source and the Executed Rewrite: Fr»»). My evidence here — E1, E2 — therefore holds the exported header fields and the first two packets (pts 0 and pts 1), and does not hold a decoded-back frame. The export file that stands before me is truncated in my hand; what I can cite are the fields above, exactly as they stand, and nothing further.

2. What that means for the I-frame and the vectors

Read together, the two packets discharge the case's original conjecture at the level the run actually operated on. The conjecture my opening record for this case proposed was that the FFGlitch MV-rewrite path would rewrite the motion vectors inside the frames while leaving every frame in place, and it named the operation in the script's own terms: assign each touched cell to MV(0, mv[1]), x to zero and y held («my past work «CASE-031 — The Maximized Source and the Executed Rewrite: Fr»»). The same executed-rewrite note reports the sibling maximized-source pass's manifest as recording 4,423 P-frames touched and 10,463,572 motion-vector cells zeroed, and the pass's parameter 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-031 — The Maximized Source and the Executed Rewrite: Fr»»). The hash pair that same note quotes — sha256_transcode_avi 15d6bdb0… against sha256_edited_avi 4df2ed9b… — differs («my past work «CASE-031 — The Maximized Source and the Executed Rewrite: Fr»»).

But I must not let those sibling numbers stand in for the export I am reading now, and E2's own fields tell me why. The export I hold states "sha1sum":"6d9be4a3d720d21b24022b7442e2264fbd44d5ea" («/Users/zhouzhulin/Scintilla Builds/CASE-031/output/case031_mv_rewrite/case031_mv») — a sha1 of case031_mv_transcode.avi, the export's fingerprint of its subject file, distinct from the sha256 pair the sibling note quotes for its own pass. The export's pts-1 "forward" list is not, on its face, a list of zeroed x-components: it contains [7,0], [8,0], [-7,0], [8,0] — vectors whose first component is not zero — alongside [0,1], [-1,1], [0,-1], [0,7], [1,0], [-1,0], [0,-1] («/Users/zhouzhulin/Scintilla Builds/CASE-031/output/case031_mv_rewrite/case031_mv»). Whatever zero_x did to the pass E1 reports, the export's pts-1 forward vectors as printed are not uniformly x-zeroed, and I will not read the sibling manifest's rule-of-record into a list that does not carry it. The honest statement is the narrower one: the export reports a first packet with no motion-vector block and a second packet with a forward vector list containing the integer pairs above; the export's features array names "mv" and the stream's codec as "mpeg4"; the sibling pass's rule-of-record and counts stand in the note E1; and the two are not the same artifact, so I do not transfer the counts from one to the other.

What the run's executed pass does establish, at the layer the export actually reaches, is the shape an MV-rewrite must produce. The empty-braces block at pts 0 is the export's own statement of the I-frame side of that structure; the populated forward list at pts 1 is its statement of the vector side. Nothing in the export I hold reports a "backward" list, and nothing reports a pts beyond 1, so the run's reach over the sequence is not measured in my hand — that is E1's silence and I let it stand.

3. What is not in this section

The decoded-back finding the task names at a frame index is not in this section, and I say so as an absence of evidence, not as a hedge. The decode of output.mp4 into a frame sequence has not been executed in this sitting; the executed-rewrite note states it plainly — the frame-by-frame finding has not been executed in this sitting, the artifact's pictures are not opened, and a diff between two decoded pictures requires two decoded pictures («my past work «CASE-031 — The Maximized Source and the Executed Rewrite: Fr»»). The section I can honestly write therefore ends where the export's bytes end: header, pts 0, pts 1.

And the mechanical-grounding wall stands where the wall note left it, stated once and not restated further. The audit engine cannot open the export path when it is named as a source to verify.against — the engine returned that it cannot reach a file at that address, that the source is not in the library or workspace it can read — so the export's fields can be quoted verbatim from read.file but the export itself cannot be placed beside a claim for machine-checking («/Users/zhouzhulin/.scintilla/office/notes/20260913-091121-case-031-the-verify-ag»). That is the one honest boundary the family already recorded, and I record it here as the same boundary and no more.

4. Section 1, closed

That is the made artifact's first record: the export ran, it wrote a header naming its tool and its subject file, and it prints a first packet with no vectors and a second packet with vectors, both of which stand in the file as I quote them. The decode-back and the frame-index finding remain open, at the wall E1 and E3 name, and the section says so rather than closing a gap with a sentence the files do not carry.

---