Eyevinn / mp4ff / 34092861338

82%

push

github

feat(mp4): resolve overlapping fragments during defragmentation

A fragment whose tfdt re-declares an earlier decode time supersedes the
earlier samples of its track (a retransmission): the fragment appearing
later in the file wins, whole re-sent fragments disappear, superseded
tails are trimmed at sample granularity, and the timeline continues
from the declaring fragment, whether or not the re-sent bytes are
identical. Non-overlapping input converts byte-identically to before.

Ambiguous overlaps keep failing closed instead of being guessed at: an
overlap that starts inside a sample (unless it only shrinks earlier
tfdt-gap padding), any abandoned time range that no surviving later
fragment declares again (whether the superseded fragment was trimmed or
dropped whole, and with voided declarations not counting as coverage),
and overlapping files whose fragments use absolute base data offsets
are rejected, so no declared content is ever silently dropped. The
payload size bound applies to the surviving samples, so re-sent
declarations larger than the input file do not reject a file that
resolves cleanly.

The work is linear in the number of fragments. Coverage checking merges
each track's surviving declaration windows once and binary searches
them. dropTrackSamplesFrom walked track.frags backwards until a record
ended at or below the cut; records voided by earlier cuts sit above
later live records in collection order and never satisfy that test once
the cut walks below them, so each later cut rescanned the whole voided
tail: n one-sample fragments followed by n-1 fragments each rewinding
one sample took O(n^2). A parallel live slice keeps the records with
kept > 0; their sample ranges tile the samples in order, so a cut pops
the suffix with firstSample >= keep and trims at most the record
straddling keep. The firstSample+kept <= keep guard stays so a cut
landing exactly on a record boundary inside gap padding does not
advance its cutoff. Gap padding is tr... (continued)

137 of 139 new or added lines in 1 file covered. (98.56%)

21819 of 26643 relevant lines covered (81.89%)

0.82 hits per line