Allocations, constant memory and I/O, 0.8

Measured on the x64 worker (AMD Ryzen 9 7950X3D, .NET 10.0.13); method in bench.md and harness.md. The speed rows are in 0.8-x64.md and 0.8-arm64.md.

Allocation gate: zero bytes per packet on the pull path

bench pullalloc FILE...: after a full first pass the packet loop TryReadPacket(out PacketView) runs again (from the start, or over the second half of the stream when the source cannot seek) with GC.GetAllocatedBytesForCurrentThread read around it. The gate is 0 bytes; all 41 files, one or more per reader, pass. The owned path (TryReadOwnedPacket with the shared MemoryPool<byte>, each packet disposed at once) is reported: 24 bytes per packet is the IMemoryOwner wrapper; the AVI, Ogg and RF64 figures above 24 are the pool growing for packets larger than any before.

Fixed on the way: the ASF reader allocated a reassembly buffer for most video objects of wmv1-wmav1.wmv (77 B per packet) because its buffer pool threw away smaller buffers when a larger one was asked for; it now hands out the smallest buffer that fits and rounds new ones up, and the file reads at 0.

Constant working set

bench memcheck AREA FILE OUTDIR runs one operation on one file in a fresh process and prints the process's peak resident set (bench/memory.sh runs the matrix; each output, up to 4 GiB, is deleted after its run). The files past 4 GiB come from tools/corpus/generate.sh on the worker and are never committed. The resident set before any work is 28.9 MiB. Remux goes to Matroska on disk, packaging to HLS (CMAF) on disk, repair rebuilds the index into a new file, and the tag edit is SaveAs with four common fields changed.

Demux, repair and tag edits peak within 10 MiB of their small-file figure at 4 GiB. Remux grows from about 50 to 65-85 MiB. Packaging follows the segment, not the input (u76; the first run of the table above had 173 and 189 MiB for the two 4 GiB inputs and 50 for the 27 MB file). The packager holds one segment per track, and a segment is as large as the bit rate times the segment duration: these two test files run at 43 Mbit/s, so a 6 s segment is 32 MiB. The cause of the extra memory was copies of that segment, not the segments written so far: the muxer kept the open fragment in one array that grew by doubling through the shared pool, and the segment buffer doubled beside it, leaving a chain of dead arrays. The fragment is now kept in reusable 256 KiB chunks and the segment buffer is sized once from the muxer's byte count and reused, so the 4 GiB inputs peak at 112 and 130 MiB (two runs each, within 0.3 MiB) and the 27 MB file at 47. The 4.2 GB MKV at other segment lengths: 2 s (10.7 MiB segments) 92 MiB, 6 s 130, 12 s 192, so the peak is about 29 MiB plus 2.5 times the largest segment; a file of any length with the same bit rate peaks the same. The buffer is bounded by MediaLimits.MaxSegmentBytes (256 MiB default; a larger segment raises MediaLimitExceededException) and documented in packaging.md. The live-mode soak is below.

Structural-only reads (probe and metadata)

io-results.txt lists every file: bytes read and calls through strace on the file, and bytes / HTTP range requests through the local range server, next to ffprobe 7.0.2, MediaInfo 26.10 and ExifTool 13.60 on the same files (1,000+ files, 13 families). "Ours" opens the file and reads its tags and basic facts. Summary of the ours/http column against the two tools that can read over HTTP:

Ours is structural: the median probe reads 8 KB (ISO BMFF, AMR) to 266 KB (MPEG), in 3 to 12 requests, on files from 0.2 MB to 4.4 GB, and a movie box at the end of a 4.4 GB file costs one seek (1,069,403 bytes in 7 requests). Where the figure is above 1 MiB the format forces a scan; each case:

36 of the 1,000+ files read more than 1 MiB. The ISO BMFF and Matroska cases read about as much as ffprobe does. The MPEG cases below the documented bound are the front and tail windows; The four transport streams that read past the documented bound in the first run are fixed (u76). Per stream, ours over HTTP before and after (bytes / requests), next to ffprobe 7.0.2 and MediaInfo 26.10 over HTTP:

The cause was the rewind: after the tables are found, or after the streams are guessed, the probe goes back to the start of the stream so each stream's first frame describes it, and that second pass went to the source again. It is now answered from a copy of the first pass (at most 6.5 MB, held only while the stream opens), so no range is requested twice, and the table search is bounded at 6 MB. What remains above 5 MB + 1 MiB is exactly the table search: vid_0x80.ts needs 5.77 MB to reach its PAT and PMT, and a stream without tables costs the full 6 MB before it is guessed (docs/mpeg.md). The whole MPEG family (151 files) was measured again: only these four, libmpeg2bug.ts and res_change_ffmpeg_aspect.ts (both a little lower) changed; the medians are the same (ours / ffprobe / MediaInfo / ExifTool, bytes and reads: transport streams 476,352 B in 3 / 470,524 B in 23 / 240,264 B in 4 / 58,864 B in 9; M2TS 836,352 in 3 / 850,760 in 34 / 582,144 in 9 / 91,888 in 13; program streams 1,472,526 in 4 / 1,198,224 in 46 / 1,316,160 in 20 / 284,400 in 36; elementary streams 143,531 in 2 / 65,536 in 2 / 110,562 in 2). The full table is io-results.txt.

AVI changed in this stage: the header list is read through a 32 KiB front cache and a read-ahead window. Counted as read-class system calls on the file made by the avi-probe bench cell (open, track list, duration, tags; bench/iocount.sh, strace), a probe makes 7 to 9 reads of the file instead of 85 to 94: the 4.6 GB OpenDML file odml-4p6gb.avi 94 before (commit 72741b0) and 7 after (172,032 bytes), tagged-mpeg4-mp3.avi 89 and 9, GoneNutty.avi 85 before. The 0.8.0-preview.1 tag and the current code give the same 7 and 9; the "50" and "48" first written for the 4.6 GB file in this file and in the 0.8 CHANGELOG entry do not reproduce and were wrong. The io table above counts something else: ours/strace in io-results.txt is the number of reads our reader asks of the file source while it opens the file and reads its tags and basic facts (io --metadata: 10 for the 4.6 GB file, 8 without the metadata), and ours/http the HTTP range requests of the same run (9 requests, 172,044 bytes). The avi-probe row went from 1.95x to 0.52x of the fastest comparator. Over HTTP the median probe is 114,509 B in 9 requests (before: 4,559 B in 32 requests; the whole table is above). It trades bytes for round trips; an 8 KiB window gave 45 KB in 10 requests and is left as a follow-up because the speed rows were taken with this build.