Eyevinn / mp4ff / 37002244250

83%

push

github

perf(mp4): encode fragments without allocating

Fragment.Encode called Encode on every top-level box, and each box's Encode made a slice writer and a buffer of its own size, encoded into it and wrote it out: 13 allocations for a fragment of one sample. Encode now sizes everything but the mdat payloads, assembles those bytes with EncodeSW in one buffer from a sync.Pool, and writes the buffer up to each mdat header followed by the mdat data parts directly, so media data is still never copied. The FixedSliceWriter lives in the pooled struct too, since it would otherwise escape to the heap as a bits.SliceWriter.

SetTrunDataOffsets collected the truns in a new slice and sorted them with sort.Slice. It now uses an 8-element array on the stack and slices.SortFunc, and skips sorting a single trun, which also takes allocations off EncodeSW.

BenchmarkEncodeFragments (testdata/1.m4s as 60 one-sample fragments, Apple M4 Pro, n=8):
- Encode: 11.4 µs -> 6.1 µs, 13 -> 0 allocations per fragment
- EncodeSW: 8.1 µs -> 6.7 µs, 3 -> 1 allocation per fragment (the remaining one is the benchmark's own writer)

TestFragmentEncodeMatchesEncodeSW checks that Encode and EncodeSW write the same bytes for every fragment of the fragmented test files, also with lazily decoded mdat. TestFragmentEncodeTopLevelBoxes covers emsg and prft before moof and 12 interleaved truns, more than the stack array holds. TestFragmentEncodeAllocations fails on master with 13 allocations.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

39 of 49 new or added lines in 1 file covered. (79.59%)

23025 of 27898 relevant lines covered (82.53%)

0.83 hits per line