1635960 - MP4Metadata.test_case_mp4: test_case_1181220.mp4 incorrectly expects parse failure

Status: RESOLVED FIXED

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

Description

[Jon Bauman [:jbauman:]]

The second track contains an fmra (OriginalFormatBox) box with the following 4 bytes values: 109, 112, 180, 97. This does not represent a valid UTF-8 string, so versions of mp4parse-rust prior to 761cdd8 would fail to parse the file since the read_frma function returned a Result<String>. Subsequent versions (which have not yet been added to mozilla-central) change the return type to Result<TryString> (an alias for TryVec<u8>, a vector which uses fallible allocation), and so parsing succeeds.

According to ISO/IEC 14496-12:2015, the frma box's contents are not guaranteed to be UTF-8, so this file should successfully parse:

8.12.2.2 Syntax

aligned(8) class OriginalFormatBox(codingname) extends Box ('frma') {
   unsigned int(32)  data_format = codingname;
                     // format of decrypted, encoded data (in case of protection)
                     // or un-transformed sample entry (in case of restriction
                     // and complete track information)
}

8.12.2.3 Semantics

data_format is the four‐character‐code of the original un‐transformed sample entry (e.g. ‘mp4v’ if the stream contains protected or restricted MPEG‐4 visual material).

Comment 1

[Jon Bauman [:jbauman:]]

Attachment: Bug 1635960 - MP4Metadata.test_case_mp4: test_case_1181220.mp4 incorrectly expects parse failure. r=kinetik

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5228e6f8cf0d
MP4Metadata.test_case_mp4: test_case_1181220.mp4 incorrectly expects parse failure. r=kinetik

Comment 3

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/5228e6f8cf0d