With media.rust.test_mode enabled while streaming from my home Plex install, I hit the assert testing for infoRust. It looks like we completely fail to parse the M4A. Logging shows: FileTypeBox { major_brand: M4A , minor_version: 0, compatible_brands: [M4A , mp42, isom, ] } MovieHeaderBox { timescale: 44100, duration: 8032256 } TrackHeaderBox { track_id: 1, disabled: true, duration: 8032256, width: 0, height: 0 } MediaHeaderBox { timescale: 44100, duration: 8032256 } HandlerBox { handler_type: soun } bad parser state: 1 content bytes left Dropping 1 bytes in 'hdlr' Dropping 65859 bytes in 'mdia' Dropping 65894 bytes in 'trak' Dropping 117806 bytes in 'moov' [MediaPDecoder #1]: D/MP4Metadata rust parser returned 2 [MediaPDecoder #1]: W/MP4Metadata rust parser error 1 counting tracks [MediaPDecoder #1]: I/MP4Metadata audio tracks found: stagefright=1 rust=0 [MediaPDecoder #1]: W/MP4Metadata rust parser error 1 counting tracks [MediaPDecoder #1]: W/MP4Metadata rust parser error 1 counting tracks [MediaPDecoder #1]: W/MP4Metadata rust parser error 1 counting tracks [MediaPDecoder #1]: I/MP4Metadata audio tracks found: stagefright=1 rust=0 [MediaPDecoder #1]: W/MP4Metadata rust parser error 1 counting tracks [MediaPDecoder #1]: W/MP4Metadata rust parser error 1 counting tracks [MediaPDecoder #1]: W/MP4Metadata rust parser error 1 counting tracks [MediaPDecoder #1]: I/MP4Metadata audio tracks found: stagefright=1 rust=0 [MediaPDecoder #1]: W/MP4Metadata rust parser error 1 counting tracks [MediaPDecoder #1]: W/MP4Metadata rust parser error 1 counting tracks Assertion failure: infoRust, at /home/kinetik/mozilla/gecko/media/libstagefright/binding/MP4Metadata.cpp:285

Here's the ftyp/moov. The original source is copyright, but there's no music data included in this attachment, just the metadata.

It's choking on the "hdlr" atom: 00000120: 0000 0022 6864 6c72 0000 0000 0000 0000 ..."hdlr........ ^^^^ ^^^^ 34 bytes 00000130: 736f 756e 0000 0000 0000 0000 0000 0000 soun............ 00000140: 0000 .. ^^^^ 2 byte "name" field read_null_terminated_string is passed the src and a count of 2 bytes, but bails after reading the first null byte, leaving 1 byte remaining to be read.

Fixed pushed upstream: https://github.com/mozilla/mp4parse-rust/pull/63

This particular bug also shows up via: http://jalopnik.com/the-ford-mustang-gt350-has-holes-in-the-exhaust-for-the-1792364176?utm_campaign=socialflow_jalopnik_facebook&utm_source=jalopnik_facebook&utm_medium=socialflow which serves us: http://x.kinja-static.com/assets/javascripts/lib/jwplayer/blank.mp4

Fixed in bug 1340980 landing.