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

RESOLVED FIXED in Firefox 61

Status

()

defect
RESOLVED FIXED
Last year
6 months ago

People

(Reporter: remtanmajitenshi, Assigned: jya)

Tracking

({parity-chrome, parity-edge, regression})

59 Branch
mozilla61
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox59 wontfix, firefox60 wontfix, firefox61 fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Posted 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.

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 jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/235133eeb0be
Update mp4parse-rust to 9e70cb4. r=padenot
https://hg.mozilla.org/mozilla-central/rev/235133eeb0be
Status: NEW → RESOLVED
Closed: Last year
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: 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.