Eyevinn / mp4ff / 37462882771

83%

push

github

feat(mp4): add FragmentDecoder and ReadFragmentBytes to decode a stream without allocating

Decoding a fragment from a slice builds a new box tree: on one-sample fragments DecodeFileSR makes 14 allocations per fragment for the boxes and their lists, which is what a reader of a live stream pays for every sample.

FragmentDecoder decodes fragment after fragment and decodes each box into the box of the same type in the previous fragment, keeping its storage, such as the sample list of the trun and the reference list of the sidx. Top-level boxes are matched by type, and boxes the last fragment did not have, such as the styp of the first fragment of a segment, are kept for later ones; boxes inside the moof are matched by position. The box header is read with its type as bytes, and a type switch on the concrete box types decides whether a box can be decoded into, so a repeated layout costs neither a lookup of the type nor an interface conversion. Boxes of other types, such as prft and emsg, and the first fragment, are decoded as by DecodeBoxSR. The mdat data views the input, as with DecodeFileSR. DecodeSR returns io.ErrUnexpectedEOF when its input ends inside a fragment, also inside the mdat, which DecodeFileSR accepts with empty data; boxes after the last mdat, such as an mfra, count as the start of a fragment.

ReadFragmentBytes reads the boxes of the next fragment from an io.Reader and appends them to a caller's buffer, growing it only as data arrives, so a box size that the stream does not back with data cannot make it allocate much more than it has read. bits.FixedSliceReader.Reset reuses one reader for buffer after buffer.

moof, traf, mfhd, tfhd, tfdt, trun, mdat, sidx and styp get a decodeSRInto method that decodes as their DecodeXSR function. The DecodeXSR functions, decodeHeaderSR and the loop of DecodeContainerChildrenSR keep their own code, since going through the reusing variants made DecodeFileSR 23% slower on one-sample fragments. DecodeConta... (continued)

298 of 384 new or added lines in 13 files covered. (77.6%)

23687 of 28671 relevant lines covered (82.62%)

0.83 hits per line