Closed Bug 1448762 Opened 5 years ago Closed 5 years ago

Certain mp4 could not be decoded in new Firefox, while plays fine in ESR 52


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

59 Branch
Not set



Tracking Status
firefox-esr52 --- unaffected
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- fixed


(Reporter: remtanmajitenshi, Assigned: jya)



(Keywords: parity-chrome, parity-edge, regression)


(2 files, 1 obsolete file)

Attached video 15210462150370.mp4
Attached file plays without problem in Firefox ESR 52.7.2 and Chrome 65. But not in Firefox 59 and Nightly.

Actual results:

"No video with supported format and MIME" message.
In console:
Media resource path/15210462150370.mp4 could not be decoded, error: Error Code: NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006)
Details: class RefPtr<class mozilla::MozPromise<class mozilla::MediaResult,class mozilla::MediaResult,1> > __cdecl mozilla::MP4Demuxer::Init(void): Parse MP4 metadata failed

Expected results:

Video should play.
Assignee: nobody → jyavenard
Ignoring an issue with the rust mp4 demuxer, the sample table of this file is invalid. In particular the Sample To Chunk Box (ISO/IEC 14496-12:2015 8.7.4) contains rubbish data with the value of first_chunk always set to 1 for all samples.

Need to find a way to ignore it if it's invalid, and find the samples without it.
Comment on attachment 8963262 [details]
Bug 1448762 - Update mp4parse-rust to 9e70cb4.

Reviewed on the PR.  We need to merge there and update in Gecko via
Attachment #8963262 - Flags: review?(kinetik)
Comment on attachment 8963263 [details]
Bug 1448762 - P2. Ignore sctc invalid entries.

Reviewed on the PR.  We need to merge there and update in Gecko via
Attachment #8963263 - Flags: review?(kinetik)
Attachment #8963263 - Attachment is obsolete: true
Comment on attachment 8963262 [details]
Bug 1448762 - Update mp4parse-rust to 9e70cb4.
Attachment #8963262 - Flags: review?(padenot) → review+
Pushed by
Update mp4parse-rust to 9e70cb4. r=padenot
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Is this serious enough that we should consider backporting it to 60 or can it ride the 61 train to release?
Flags: needinfo?(jyavenard)
I'm not sure how serious that is... The MP4 that didn't play were invalid to start with...
The change is rather safe and as such not high risk...

so up to you :)
Flags: needinfo?(jyavenard)
If the file's invalid and we don't crash I'm leaning towards wontfix.
Hi all, I wanted to let you know that this bug is serious to us :(  

This broke recording playback for thousands of our customers and waiting until the release of 61 is about 6 weeks of pain for our customers (and our support team).  

All other browsers are working normally so we are sad to have to refer our customers to those!  If there is ANY way this can go out in the release for 60, we would be so grateful!

I hope you guys can find it in your hearts to save our support from thousands of unhappy customer complaints  and slip this into 60 :)  TIA!
I understand your concerns, however those files are technically invalid. Rejecting them is the right thing to do.

Unfortunately 60 has entered a frozen period, and such change won't be accepted.

You can fix the root caused be simply remuxing them with a tool that generates proper file. I suggest the ffmpeg utility. As only remuxing is required, it will only take less than a second to perform the operation.
Something like ffmpeg -i file.mp4 -codec copy file_fixed.mp4

Just my two cents here. We're seeing multiple reports associated with this issue:, and etc.

The argument that if a file is partially invalid it should be rejected altogether is a bit ironic coming from a web browser perspective. If so, how many HTML pages live out there should be rejected as well?

You need to log in before you can comment on or make changes to this bug.