Closed Bug 1448762 Opened 3 years ago Closed 3 years ago
Certain mp4 could not be decoded in new Firefox, while plays fine in ESR 52
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.
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. https://reviewboard.mozilla.org/r/232148/#review238654 Reviewed on the PR. We need to merge there and update in Gecko via update.sh.
Attachment #8963262 - Flags: review?(kinetik)
Comment on attachment 8963263 [details] Bug 1448762 - P2. Ignore sctc invalid entries. https://reviewboard.mozilla.org/r/232150/#review238656 Reviewed on the PR. We need to merge there and update in Gecko via update.sh.
Attachment #8963263 - Flags: review?(kinetik)
Attachment #8963263 - Attachment is obsolete: true
Comment on attachment 8963262 [details] Bug 1448762 - Update mp4parse-rust to 9e70cb4. https://reviewboard.mozilla.org/r/232148/#review240480
Attachment #8963262 - Flags: review?(padenot) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/235133eeb0be Update mp4parse-rust to 9e70cb4. r=padenot
Is this serious enough that we should consider backporting it to 60 or can it ride the 61 train to release?
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 :)
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
You need to log in before you can comment on or make changes to this bug.