Eyevinn / mp4ff / 37210733037

83%

push

github

perf(mp4): find the trun data of built fragments in one pass

Reading the samples of a fragment that has not been decoded took time quadratic in its number of truns, since trunOffsetInWriteOrder adds up the data of all truns of the fragment for each trun, and Samples resolved every trun twice. A fragment built with AddFullSampleToTrack from interleaved tracks has one trun per sample, so reading both tracks of 300 such samples each with AppendFullSamples took 294 us, against 5.6 us for the same fragment encoded and decoded. A trunWalk now walks the truns of all trafs once, in write order, when the truns of every traf are in write order, as AddSampleToTrack creates them. That takes 7.5 us. Other built fragments still use trunOffsetInWriteOrder for each trun. The callers choose between the walk and trunOffsetInMdat, which decoded fragments use, so that trunOffsetInMdat gets no added call; with a call there, reading decoded fragments measured about 5% slower.

MdatBox.ReadData and CopyData slice Data directly when there are no DataParts, instead of finding the range with the payload cursor that #620 added. ReadData takes 2.7 ns instead of 4.1 ns.

BenchmarkInterleavedFragmentSamples and BenchmarkMdatReadData measure both cases. TestBuiltFragmentTrunLayouts checks the samples of each track for interleaved, empty, equally numbered and out-of-order truns, and against what Encode writes where its layout is unambiguous. It passes on the code before this change too, so the walk gives the same offsets.

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

66 of 68 new or added lines in 2 files covered. (97.06%)

23310 of 28206 relevant lines covered (82.64%)

0.83 hits per line