1480003 - A WebM video won't play, returning NS_ERROR_DOM_MEDIA_METADATA_ERR

Status: VERIFIED FIXED

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

Description

[victor1950]

Attachment: 15326404096860.webm

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180704003137

Steps to reproduce:

Opened the attached WebM video in Firefox 61, tried doing this both from my hard drive and from a website where it was originally posted.


Actual results:

The video didn't play with NS_ERROR_DOM_MEDIA_METADATA_ERR being returned. A debug build of Firefox 61 emits an "!aWindow" assertion in AudioChannelAgent.cpp, line 137, which might or might not be a root cause of the problem. If the WebM file itself is corrupted, I would appreciate a developer telling me what exactly is wrong with it. Here someone says: "It looks like it is possible for window to be null"
https://bugzilla.mozilla.org/show_bug.cgi?id=1044773#c1
I don't know if this pertains to my situation or not.


Expected results:

This video plays fine in Chrome 67, Opera 54 and various offline video players.

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bc71ac7b9074&tochange=12d543cfa167

Suspect: 5d5dae8097ef	Nathan Froyd — Bug 993522 - fix comment in DMD.h; r=njn
	 5c509bb6f5c4	Nathan Froyd — Bug 682216 - add a memory reporter for libnestegg's memory; r=njn,kinetik
	 7c22d81c6b04	Nathan Froyd — Bug 992955 - update libnestegg to upstream commit c739433; r=kinetik


:froydnj,
Your bunch patch seems to cause the problem, can you look into this?

Comment 2

[Nathan Froyd [:froydnj]]

I would guess that libnestegg update causes the problem, but that would be a question for kinetik, really.

Comment 3

[Matthew Gregan [:kinetik]]

Yes, this looks like a (4.5 year old!) regression from https://github.com/kinetiknz/nestegg/pull/17.  It looks like we lose parser sync after reading a DefaultDuration element.  These are fairly uncommon, which is probably why this issue hasn't shown up before now.  I'm not sure if Chrome et al. parse this field (and handle it correctly) or are ignoring it like we used to.

Comment 4

[Matthew Gregan [:kinetik]]

Actually, the problem is that this file has multiple DefaultDuration elements for the video track:

|+ Segment tracks at 359
| + A track at 371
|  + Track number: 1 (track ID for mkvmerge & mkvextract: 0) at 380
[...]
|  + Default duration: 33.367ms (29.970 frames/fields per second for a video track) at 390
[...]
|  + Track type: video at 412
|  + Default duration: 33.367ms (29.970 frames/fields per second for a video track) at 415

So it's not our parsing of DefaultDuration that's broken, only the handling of duplicate DefaultDuration elements.  The Matroska/WebM spec does not permit multiple DefaultDuration per track, so I think this file is technically invalid.  Given other parsers accept it, we probably should too, so we can fix this.

It should be possible to fix this specific file with a tool such as mkvclean or anything else that will remux it into a compliant file.

Comment 5

[Matthew Gregan [:kinetik]]

https://github.com/kinetiknz/nestegg/pull/60

Comment 6

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/251cbf54ce91

Comment 7

[Cristian Fogel [:cfogel]]

Was able to reproduce the issue using 62.0.
Verified with 63.0b7, 64.0a1 (2018-09-19) on win10x64, Ubuntu 16.04LTS, macOS 10.13.6 and can confirm that there is no playback issue.