Closed
Bug 1448762
Opened 6 years ago
Closed 6 years ago
Certain mp4 could not be decoded in new Firefox, while plays fine in ESR 52
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
RESOLVED
FIXED
mozilla61
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox59 | --- | wontfix |
firefox60 | --- | wontfix |
firefox61 | --- | fixed |
People
(Reporter: remtanmajitenshi, Assigned: jya)
References
Details
(Keywords: parity-chrome, parity-edge, regression)
Attachments
(2 files, 1 obsolete file)
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.
Updated•6 years ago
|
Comment 1•6 years ago
|
||
regression window https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=db021650476bfc8a705dc9eaaa96261d4fa5667a&tochange=a51ca572b96caacf171bcb35bf7ba32137fe7c08
Blocks: 1415809
Status: UNCONFIRMED → NEW
status-firefox59:
--- → wontfix
status-firefox60:
--- → fix-optional
Ever confirmed: true
Version: Trunk → 59 Branch
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → jyavenard
Assignee | ||
Comment 2•6 years ago
|
||
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 hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 5•6 years ago
|
||
mozreview-review |
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 6•6 years ago
|
||
mozreview-review |
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)
Comment hidden (mozreview-request) |
Assignee | ||
Updated•6 years ago
|
Attachment #8963263 -
Attachment is obsolete: true
Comment 8•6 years ago
|
||
mozreview-review |
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 jyavenard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/235133eeb0be Update mp4parse-rust to 9e70cb4. r=padenot
Comment 10•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/235133eeb0be
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Updated•6 years ago
|
status-firefox-esr52:
--- → unaffected
Comment 11•6 years ago
|
||
Is this serious enough that we should consider backporting it to 60 or can it ride the 61 train to release?
Flags: needinfo?(jyavenard)
Assignee | ||
Comment 12•6 years ago
|
||
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)
Comment 13•6 years ago
|
||
If the file's invalid and we don't crash I'm leaning towards wontfix.
Comment 14•6 years ago
|
||
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!
Assignee | ||
Comment 15•6 years ago
|
||
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
Comment 16•5 years ago
|
||
Just my two cents here. We're seeing multiple reports associated with this issue: https://github.com/savonet/liquidsoap/issues/587, https://github.com/savonet/liquidsoap/issues/588#issuecomment-409759431 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.
Description
•