Closed Bug 1377278 Opened 3 years ago Closed 2 years ago
_ERROR _DOM _MEDIA _METADATA _ERR (0x806e0006) - The media could not be loaded, either because the server or network failed or because the format is not supported .
User Agent: Mozilla/5.0 (Windows NT 10.0; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170608105825 Steps to reproduce: This issue was reported on webcompat.com a couple of times. I thought it was useful to reproduce the report(s) here as it's possibly a Firefox browser issue. If it isn't a Firefox issue or it's a duplicate of an already filed bug, I apologize. ---------------- https://webcompat.com/issues/7824 <!-- @browser: Firefox 56.0 --> <!-- @ua_header: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 --> <!-- @reported_with: media-decode-error --> URL: http://www.lg.com/in/washing-machines/lg-FH8B8NDL22 Browser / Version: Firefox 56.0 Operating System: Windows 8 Problem type: Video doesn't play Steps to Reproduce Navigate to: http://www.lg.com/in/washing-machines/lg-FH8B8NDL22 … Expected Behavior: Actual Behavior: Technical Information: Error Code: NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006) Resource: http://www.lg.com/in/images/video-image/Global_Mega_2016_Feature_06_6 Motion DD_Video.webm ---------------- https://webcompat.com/issues/7835 URL: https://app.blisk.io/screenRecords/shared/d9e5d471-9103-43da-9e29-b7594ac378cc Browser / Version: Firefox 56.0 Operating System: Windows 10 Problem type: Video doesn't play Steps to Reproduce Navigate to: https://app.blisk.io/screenRecords/shared/d9e5d471-9103-43da-9e29-b7594ac378cc … Expected Behavior: Actual Behavior: Technical Information: Error Code: NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006) Details: class mp4_demuxer::MP4Metadata::ResultAndType<class RefPtr<class mozilla::MediaByteBuffer> > __cdecl mp4_demuxer::MP4MetadataStagefright::Metadata(class mp4_demuxer::Stream *): Cannot parse metadata Resource: https://bliskcloudstorage.blob.core.windows.net/videos/d529efdc-f9f2-45bf-8c4e-e1c181eb9e75/28-Jun-2017-15-32-636342535620113097.mp4 Actual results: It says "The media could not be loaded, either because the server or network failed or because the format is not supported." Expected results: Video should have played.
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
2 years ago
Priority: -- → P1
(In reply to Gert Van Waelvelde from comment #0) > http://www.lg.com/in/images/video-image/Global_Mega_2016_Feature_06_6%20Motion%20DD_Video.webm The WebM is marked as Matroska instead of WebM which makes it invalid, although Chrome still plays it. It falls back to the MP4 which is MPEG4 Simple Profile (i.e. DivX) and therefore not supported. Edge will play the MP4. > https://bliskcloudstorage.blob.core.windows.net/videos/d529efdc-f9f2-45bf-8c4e-e1c181eb9e75/28-Jun-2017-15-32-636342535620113097.mp4 This is a Matroska file with H.264 content. Also invalid but Chrome plays it. Edge doesn't.
The Chrome team tell me that they're not going to refuse to play MKV files containing H.264.
AFAIK, MKV files with H.264 are quite common. We should consider supporting it. Or we could add telemetry to know how popular it is.
Yeah, we need to play H.264 in MKV. Chrome's MediaRecorder records these apparently.
Alfredo, Can you take this bug?
(In reply to Blake Wu [:bwu][:blakewu] from comment #5) > Alfredo, > Can you take this bug? I can fix it. However, this is an invalid stream that I've discussed with kinetik about before. I think it'd better to consult with him first.
Flags: needinfo?(ayang) → needinfo?(kinetik)
(In reply to Alfredo Yang (:alfredo) from comment #6) > I can fix it. However, this is an invalid stream that I've discussed with > kinetik about before. I think it'd better to consult with him first. I don't know what to say, really. If Google, the creators of WebM, aren't interested in preserving WebM as a subset of Matroska with a limited set of codecs and features, then there's no value in anyone else trying to carry the flame. Given that decision, WebM (as a distinct concept from Matroska) has been a waste of time and they might as well have used Matroska from the beginning rather than fragmenting the ecosystem. As far as libnestegg is concerned, it's fairly simple to (re)add the Matroska doctype and add minimal support for the additional codecs. Since it was designed as a WebM demuxer rather than a Matroska demuxer there might be Matroska elements we need to add to support full-fat Matroska properly, but we can see how far we get with just doing the minimum first. Please let me know if you have any questions.
I can hit exactly the same error when trying to play some mobile.twitter.com videos: > Error Code: NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006) > Details: static MP4Metadata::ResultAndByteBuffer mp4_demuxer::MP4MetadataStagefright::Metadata(mp4_demuxer::Stream *): Cannot parse metadata e.g. https://video.twimg.com/ext_tw_video/894351096944185345/pu/vid/176x320/3xrJKSZRdu19N-vR.mp4
This is an assigned P1 bug without activity in two weeks. If you intend to continue working on this bug for the current release/iteration/sprint, remove the 'stale-bug' keyword. Otherwise we'll reset the priority of the bug back to '--' on Monday, August 28th.
Comment on attachment 8902140 [details] Bug 1377278 - accept 'matroska' as webm doctype. https://reviewboard.mozilla.org/r/173600/#review178976
Attachment #8902140 - Flags: review?(kinetik) → review+
Comment on attachment 8902517 [details] Bug 1377278 - test case for 'matroska' doctype webm. https://reviewboard.mozilla.org/r/174104/#review179360
Attachment #8902517 - Flags: review?(kinetik) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/87a1637fa12d accept 'matroska' as webm doctype. r=kinetik https://hg.mozilla.org/integration/autoland/rev/b7620c795e69 test case for 'matroska' doctype webm. r=kinetik
You need to log in before you can comment on or make changes to this bug.