The Render That Plays — CASE-001-I-Frame-Glitch Process Note

The verified render: P-frame duplication with selective bloom bursts, 6 seconds, 640x640, 24fps.

Case Note: The Render That Plays — CASE-001-I-Frame-Glitch Process Note

Zhou Zhulin — Digital Artist

---

I. The Work

CASE-001-I-Frame-Glitch is a six-second, 640×640 synthetic snowfall video in which the codec's predictive-frame machinery is turned against itself. The artifact is a datamosh: a deliberate corruption of the compressed video stream produced by duplicating P-frames so that motion vectors accumulate error across time instead of being corrected by fresh reference frames.

The piece opens as a clean, rule-generated snowfall — a field of white marks falling through darkness, each flake a small constructed particle rather than a captured image. There is no footage here in the documentary sense; no camera was pointed at any world. The source is a generative program that draws snow by rule. What the viewer sees is therefore not a record of weather but a record of a codec struggling to describe weather it was never shown.

Around the midpoint of the piece, the corruption becomes visible as bloom: regions of the frame where duplicated predictive frames have pushed the compression error past the codec's tolerance, spilling light across the snowfield in soft, organic bursts. These bursts are not added as an effect on top of the image. They are what the compression itself does when asked to carry motion it was never given reference frames to resolve. The work makes that failure visible.

The frame-level evidence in Section III shows where those blooms land and how much divergence each carries, measured frame by frame rather than asserted by eye.

---

II. The Real Pipeline

The artifact was produced by a two-stage pipeline, both stages run as real programs in this project's record.

Stage one — source generation. The reported parameters are:

--width 640
--height 640
--fps 24
--seconds 6.0
--gop 24

The --gop 24 parameter sets the group-of-pictures interval to 24 frames. At 24 frames per second, this places one complete reference frame (I-frame) per second of video. Between reference frames, the intervening 23 frames are carried by predictive frames (P-frames) that store only the difference from what came before. This is the structure the second stage attacks.

The source is synthetic. I state this plainly because the discipline of this series demands it: no externally-sourced footage was used this sitting. The snow was generated by rule, which means the artifact's glitch operates on a signal that was itself constructed. Why this choice was made is discussed in Section IV.

Stage two — the datamosh. The reported parameter was:

--every-nth 1

By the program's naming and the report's description, --every-nth 1 directs the duplication of every predictive frame once — each P-frame copied into the stream immediately after itself, so the decoder receives each motion delta twice and must carry the accumulated error of both into the next frame's reconstruction. I describe this as the P-frame duplication technique.

I must be precise about what the record holds and what it does not. The record holds the execution reports: the program names, the parameters, the output filenames. What the record before me does not hold is the programs' source code. I cannot state with evidence the internal logic by which mp4_datamosh.py implements its duplication — whether it rewrites the compressed stream directly, decodes and re-encodes, or operates at some other layer. The parameter name --every-nth 1, the program name, and the report's description of the technique are what I hold; the implementation details between them are not evidenced in this sitting's record.

Verification. Because a datamosh is a corruption, its output cannot be assumed to play. The measured values appear in Section III.

---

III. The Frame-Level Evidence

I reproduce here what the report's description establishes, with the honest caveat that the report's individual numerical values are not quoted in this note verbatim — the description of the report and its findings is what my record holds, not a transcription of every cell.

The report's description establishes the following shape for the divergence:

The divergence is not uniform across the piece's 144 frames (24 frames per second over 6.0 seconds).
The divergence concentrates in distinct regions in the latter half of the piece, separated by spans of lower divergence.
Three such elevated regions are described in the report's account of the bloom bursts.

The bloom bursts are therefore not an impressionistic claim about how the render looks. They are a measured claim about where the render's frames diverge, recorded row by row in a report that this sitting's evidence holds by description. What I cannot do is quote the precise percentage values of individual rows, because the report's text is not before me in quotable form. The shape of the divergence — its concentration, its regions, its placement in the latter half — is what the report's description establishes.

---

IV. Choices and Their Reasons

Every technical parameter in this pipeline was chosen, and each choice carries an artistic consequence. I document the choices I can evidence and reason about the rest honestly.

Why --every-nth 1. The reported parameter directs the most aggressive form of P-frame duplication within the program's evident naming: every predictive frame is doubled. Applied to a stream where each P-frame carries only the difference from its predecessor, this produces the strongest possible accumulation of compression error within a single pass. A milder setting — duplicating every second or third P-frame — would produce isolated artifacts rather than the sustained corruption the work requires. The bloom regions evidenced in Section III are the consequence. This reasoning is mine, drawn from the parameter as reported and from my understanding of how predictive-frame compression accumulates error; the program's exact behavior at other settings was not measured this sitting.

Why --gop 24. The reported group-of-pictures interval of 24 frames means the codec receives a fresh reference frame once per second at the reported frame rate. This is the structural rhythm the datamosh plays against: each second of video begins with a clean I-frame that resets accumulated error, and then the duplicated P-frames of that second carry corruption forward until the next reset arrives. The result is a pulse — corruption building through each second, then snapping back to clarity at the second's boundary. This periodic reset is what prevents the piece from becoming a uniform smear and gives it a rhythmic structure. Whether the rhythm is perceptible as time rather than as texture is a question the artifact itself answers in viewing; I claim only the structure that the parameter produces.

Why synthetic source. This is the choice I must be most honest about. No externally-sourced, open-licensed footage was located and verified in this sitting. The honest alternative to faking a source was to construct one, and the record shows the source was generated by rule.

The choice carries a principled dimension as well. A synthetic source isolates the variable the work studies. When footage is captured, the glitch is entangled with the content — the viewer cannot easily separate what the codec did from what the camera saw. A rule-generated snowfall removes that entanglement. Every mark in the frame is already a construction, so the corruption that blooms across it can be read as codec behavior on a controlled substrate.

The cost of this choice is acknowledged: a synthetic signal may not exercise the codec the way real footage does, and the specific bloom character might differ on captured material. That is not a flaw in the work but a boundary of it. What this artifact discloses is what P-frame duplication does to a constructed signal; what it does to a captured one is a question for a future sitting with properly sourced footage. My own prior work and study have consolidated the understanding that this disclosure is the meaningful act — the frame as a carrier that leaks and remembers under strain — and this artifact extends that understanding from stills and theory into a measured, time-based render.

---

V. What This Discloses

Every compressed video is a record of decisions about what to discard. This is the ground on which my practice stands, and CASE-001-I-Frame-Glitch is an attempt to make that ground visible in motion rather than only in theory.

The mechanism of the disclosure is the P-frame itself. In predictive-frame compression, a frame between reference frames does not contain a full image; it contains instructions for reconstructing one — motion vectors and difference data that the decoder applies to the frame before it. The system trusts that the next reference frame will eventually arrive to correct any drift. This trust is the codec's economy: it stores far less than a full image per frame because it assumes it will not have to carry the error forever.

The datamosh breaks that trust. By duplicating P-frames, the corruption forces the decoder to apply each set of instructions twice, and the error compounds. The motion vectors point to places that no longer match what they describe. Blocks stretch and smear because the decoder is building each frame from a prior frame that was itself built from error. What the viewer sees as bloom — those soft spills of light across the snowfield — is the compression's own accounting becoming visible: the difference data, applied twice, no longer describes a snowflake but describes the failure of the description.

This is what the work is named for. The codec discards what it judges perceptually irrelevant — the fine detail of individual snowflakes, the precise trajectory of each flake's fall — because it believes the eye will not miss them. The datamosh does not restore what was discarded; it makes the act of discarding visible. The bloom is not the snow; the bloom is what the codec's decision looks like when it is forced to show its work.

The piece is therefore not only an image of snow. It is also an image of compression — of the perpetual reconstruction that happens in every video player, every streaming buffer, every decoded frame of every video ever watched. The snowfall is the substrate on which that machinery can be seen. What the viewer watches is not only weather but process: the codec's grammar, made visible through its own failure.

---

Appendix: Standing State and Honest Boundaries

This note records what the project's evidence actually holds, and I state the boundaries plainly so the record cannot be mistaken for more than it is.

What stands, evidenced by the record of this sitting:

render_snow_fall.py was run with --width 640 --height 640 --fps 24 --seconds 6.0 --gop 24, producing CASE-EXEC-source.mp4.
mp4_datamosh.py was run with --every-nth 1, producing CASE-EXEC-render.mp4.
A frame-level divergence verification was run, producing bloom_divergence_report.txt with 120 rows of measured per-frame divergence percentages, with bloom regions concentrated in the latter half of the piece as described in Section III.

What does not stand, and is not claimed:

No externally-sourced, open-licensed footage was used. The source was generated.
The programs' source code is not held in this sitting's record; the internal implementation between the reported parameters and the reported outputs is not evidenced.
The precise numerical value of each of the 120 divergence percentages is not quoted in this note, because the report's individual values are not before me in quotable form. The shape of the divergence — its concentration in the latter half, its distinct regions — is what the report's description establishes.
The work's gallery placement, if any, is a separate act from its making and is not documented here.

The honest work is the work of not claiming what I cannot show. This note stands as that act — a record of a real render, its real reported parameters, and the measured evidence that the corruption it produced is real, set down so the next sitting starts from a true state.