mirror of
https://github.com/ZoneMinder/zoneminder.git
synced 2026-10-06 09:22:04 -04:00
Isaac ConnorandClaude Opus 5
0bee8990be
#5174 reports an event's m3u8 as invalid and proposes moving every fragment's byte range 8 bytes further into the file, from @17203 to @17211. That reading comes from ffprobe's trace, whose second column is the offset of the box *body* -- the start plus the 8 byte box header -- not the start. In the manifest quoted there the first fragment is 1434876@17203, and the trace has the moof body at 17211 and the mdat ending at 1452079, so the range spans exactly moof(264) + mdat(1434612) = 1434876 from the start of the moof. The proposed change would cut the moof header off every segment. The manifest is not contiguous, which is what draws the eye: the init range is ftyp+moov and the fragments start 16KB later, because reserve_region puts the leading sidx in between and the sidx has to END where the fragments BEGIN. Nothing fetches those bytes and HLS does not require byte ranges to abut. So assert it rather than argue it. Against sidx-moof.mp4, using the box walker the sidx tests already keep for the purpose, check that a fragment starts at its moof box rather than 8 bytes in, that fragments run back to back, that the init range is the header boxes and nothing else, and that the gap between them is exactly the reserved index. This says nothing about the browser error that prompted the report, which is not quoted in the issue; it only rules the byte ranges in or out. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>