2047239 - mp4parse rejects MP4 files when nclx colr box omits the full_range_flag byte (fatal BitReaderError)

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P2)

Description

[Jim Mathies [:jimm]]

Attachment: bug-2044339-triage.md

Diagnosed: mp4parse rejects the whole file with InvalidData(BitReaderError). The video track's colr box is a non-conformant 18-byte nclx box — it ends after matrix_coefficients and omits the trailing full_range_flag+reserved byte (conformant nclx colr is 19 bytes):

00 00 00 12 63 6f 6c 72 6e 63 6c 78 00 01 00 01 00 01

In read_colr, the nclx branch reads the three 2-byte fields then does bit_reader.read_bool()? for full_range_flag against an empty buffer → BitReaderError, which propagates fatally up through stsd/stbl/moov and fails mp4parse_new entirely. Chrome/Safari/QuickTime tolerate the short (informational) colr box, so they play it.

Suggested fix: in read_colr, treat a missing full_range_flag byte gracefully (default false), and/or make colr parse errors non-fatal in read_video_sample_entry (same pattern as the esds DS-descriptor BitReaderError tolerance). This is upstream mp4parse-rust. Reproduced locally with mp4parse_capi's dump example against the served moov.

Comment 1

[Jim Mathies [:jimm]]

This was the first bug I triaged using Opus 4.8. It went way deeper than any previous model I've worked with. Mathew, let me know if this was an accurate diagnosis, looks really solid to me.

Comment 2

[Matthew Gregan [:kinetik]]

The analysis and suggested fix are good. It looks like this is a result of muxers writing nclc boxes (from the QTFF format, a precursor to ISO BMFF) as if they're nclx since nclx is identical except for including an additional field.

Comment 3

[Matthew Gregan [:kinetik]]

https://github.com/mozilla/mp4parse-rust/pull/452

Comment 4

[Mathew Hodson]

Fixed in bug 2047467