Opening a recording no longer means copying the whole file

The header was doing the packet walk

The note says a demuxer has two jobs: read_header learns the streams, and read_packet hands the next chunk to a decoder. The old header path did both. It read the input to the end, then walked samples while that buffer was alive. Matroska, AVI, and Ogg were the expensive shape, because the packet walk also kept an owned copy of every block. The note says peak memory was about twice the file, so a 20 gigabyte Matroska file wanted on the order of 40 gigabytes just to open. MP4 was one copy. The container layout those formats use is a public specification, not a house invention. Matroska's element list is the public one.Matroska, the public layout.

The numbers the note will stand on

Same machine, release build, rusty_alloc, peak working set. A 239 MiB 1080p Matroska probe: 516 MiB to 6.2 MiB, and 283 milliseconds to 12. A 239 MiB AVI: 522 MiB to 6.2 MiB, and 372 milliseconds to 96. A 239 MiB MP4 with the index at the end: 246 MiB to 7.3 MiB, and 119 milliseconds to 17. A 220 MiB WAV: 226 MiB to 6.2 MiB, and 250 milliseconds to 49. A 15 MiB FLAC probe: 21.6 MiB to 6.2 MiB. This page did not rerun them. A stream copy of the MP4, Matroska, AVI, and WAV stayed byte-identical, the note says.the October 17 red-test brief.

What a seekable MP4 does that a pipe cannot

On a seekable file, the note says the MP4 reader walks top-level box headers, seeks past the media, reads the index, and fetches each sample by offset. A declared sample size is not an allocation. A pipe cannot seek, so a trailing index still forces a buffer. Local files take the seekable path. URLs, RTP, and HLS stay streams. That split is the limit a reader should keep: the win is for a file on disk, not for every way a recording can arrive.the software desk.

Matroska, AVI, and the formats that now stream

Matroska and WebM, the note says, read through a 64 kilobyte buffer, take Info and Tracks, and stop at the first cluster. Packets then walk one cluster child at a time. A frame count stays empty, which the note says is what ffprobe reports too, because counting every packet would read the file again. AVI walks chunks until the movie list and then yields one sub-chunk per packet. A file cut off inside the movie data now returns every complete chunk before the cut. Ogg reads a page at a time and exposes only the first decodable Opus or Vorbis stream. Page checksums are still not checked. That limit is written down.FFmpeg's format list.

FLAC frames, and tags that are not frames

FLAC used to leave as one packet. The note says it now reads metadata in the header and one frame per packet, with a CRC-16 so a sync pattern inside frame data cannot split a frame. On a 68 MiB file the demux CPU fell from about 250 milliseconds to about 115, and the decode to WAV stayed inside the noise of the old path. A 34 megabyte guitar file still reports 3,952 frames, matching ffprobe. WAV stops at the data chunk. MP3 skips a leading ID3 tag by its declared size and does not turn a trailer tag into a fake frame. Duration for MP3 stays empty. RF64 WAV remains unsupported.what a version number has to mean.

The picture tests that belong to yesterday's brief

The same tree includes debug fixes for HEVC asserts and for an empty AV2 packet. Those are the defects yesterday's brief filed from the other house note. This page will not re-try them. The new dependency is the probe: naming the streams without becoming the archive. Release HEVC was already bit-exact on the streams that note lists. The memory table above is the change a reader can check against a file size.

Where the file is supposed to open

The note says the tool is the demuxer a home computer uses after a camera or a microphone has written a file. It says the measurements are not a crates.io release. It says the home computer's live view is not wired yet. A machine that opens a local recording is a different dependency from a vendor that holds the only copy. The house page is the mechanism for the probe this brief describes.the house note.

What an outside format document does not prove

Matroska's public description and FFmpeg's format manual say how those containers are organized. They do not certify the memory numbers. They are the reason a reader can check that a cluster, a movie list, and an MP4 index are real structures and not names invented for the note. The byte-identical claim remains the note's claim about its own files. The short answer this page will stand on is this: The October 16 note says seekable MP4, Matroska, AVI, Ogg, FLAC, WAV, MP3, IVF, and Y4M no longer enter read_header as a full copy. On that note's Windows release run, a 239 MiB Matroska probe fell from 516 MiB to 6.2 MiB. A pipe still buffers an MP4. The tree is not a crates.io release.Futureweb.

What this page will re-check

A crates.io release that includes the streaming readers would move the install sentence. A correction of the 516-to-6.2 figure would move the Matroska line. A pipe that can open a trailing-index MP4 without buffering would retire the pipe sentence. Until then the working tree is the record, and the published crate is the older one. The home computer the note names is a machine on the LAN, not a vendor archive.the home computer on the LAN.