Closed Bug 1133634 Opened 8 years ago Closed 8 years ago

mp4-encoded YouTube & Vimeo videos are entirely black, on linux


(Core :: Audio/Video, defect)

Not set



Tracking Status
firefox37 --- verified
firefox38 --- verified
firefox-esr31 37+ verified


(Reporter: dholbert, Assigned: eflores)



(Keywords: regression, Whiteboard: workaround: turn off pref "media.gstreamer.enabled")


(1 file)

 1. Visit

Audio plays, but the video remains black. If I try to seek around in the video, it's still entirely black. I can hear audio, but there's no video playing.

Video should play.

(Note that the first ~1 second is supposed to be fully black, before the logo swoops into view.)


--> caused by Bug 981869, which blacklisted a gstreamer plugin.

Platform: 64-bit Linux
Firefox Version: 38.0a1 (2015-02-16)
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0

Edwin, any suggested workarounds?  Based on "risks" from bug 981869 comment 28, it sounds like this outcome wasn't anticipated.
OS version: Ubuntu 14.10 (64-bit)
Flags: needinfo?(edwin)
Keywords: regression
Summary: YouTube videos are entirely black → YouTube videos are entirely black, on linux
Hmm, maybe the audio track on the video is MP3. Should have no shortage of MP3 decoders on Ubuntu though.
Assignee: nobody → edwin
Flags: needinfo?(edwin)
The audio plays just fine -- only the video is black.

Also: FWIW, I can successfully play these videos:
 Firefox ad:
 Simon's Cat:
 Soul Pancake:
 Frozen Trailer:
 John Oliver "RadioShack" bit:

But these ones play with a fully-black video area:
 John Oliver "Tobacco" bit:
 SNL Celeb Jeopardy bit:
Sorry, I had the wrong URL for the PewDiePie video -- I mis-pasted the broken John Oliver video URL there.

All the videos listed in comment 3 are playing with the HTML5 player, fwiw. (both before & after the regression)  If I right-click them, there's an "About the HTML5 Player" entry in the context menu.

"Stats for nerds" context-menu entry shows that all the working ones have a  WebM / VP9 mime type, whereas the broken ones have this mime type:
> video/mp4; codecs="avc1.42001E, mp4a.40.2"
Summary: YouTube videos are entirely black, on linux → mp4-encoded YouTube videos are entirely black, on linux
Two more data points:
 - Disabling the pref "media.gstreamer.enable-blacklist" does NOT fix this bug. (despite my expectations). This pref was created in bug 981869, the bug that caused this regression. (That makes me wonder slightly if that pref is actually behaving as-expected.)

 - Disabling the pref "media.gstreamer.enabled" *does* fix this bug. (This seems to make YouTube serve me a *working* VP8/vorbis video stream instead of mp4, for both broken videos.)
Whiteboard: workaround: turn off pref "media.gstreamer.enabled"
I also get a black video area when playing .  (same regression range as the YouTube issue)
Summary: mp4-encoded YouTube videos are entirely black, on linux → mp4-encoded YouTube & Vimeo videos are entirely black, on linux
DOM inspector for that vimeo video shows this <video> tag:
<video poster="" src=";aksessionid=6249e4128701cc6a&amp;ns=4" preload="" x-webkit-airplay="allow"></video>

...whereas before the regression I see this instead:
<object data="" type="application/x-shockwave-flash" height="100%" width="100%"><param value="ready=flideo_1424207210466.flashReady" name="flashvars"><param value="" name="movie"><param value="true" name="allowfullscreen"><param value="always" name="allowscriptaccess"><param value="#000000" name="bgcolor"><param value="opaque" name="wmode"><param value="high" name="quality"><param value="noscale" name="scalemode"></object>

So at least in the vimeo case, it seems like part of the issue is that they're serving flash to pre-regression builds and a mp4 to post-regression builds. I'm not sure what's going on there, and I'm not 100% sure that this change coincides with bug 981869's landing.  (As noted in comment 6, though, I did verify that the fully-black-vimeo-video *does* start with bug 981869's landing, via mozregression.)
Before that rev, youtube serves vp8. With the rev, it serves mp4. I wonder if something broke in CanPlayType().
Attached patch 1133634.patchSplinter Review
So, the patch in bug 981869 tried to move some of the filtering from FactoryFilter() into IsPluginFeatureBlacklisted(), which didn't really make any sense.
Attachment #8565788 - Flags: review?(kinetik)
Attachment #8565788 - Flags: review?(kinetik) → review+
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Edwin - As per your comment in bug 981869, this bug impacts 37 as well. Can you please request uplift for Beta 4 (gtb Mon, Mar 9)?
Flags: needinfo?(edwin)
Comment on attachment 8565788 [details] [diff] [review]

Approval Request Comment
[Feature/regressing bug #]: Bug 981869
[User impact if declined]: Video playback not working on Linux
[Describe test coverage new/current, TreeHerder]: In m-c since Friday 2015-02-18 PST
[Risks and why]: Video playback not working for many Linux users
[String/UUID change made/needed]: None
Flags: needinfo?(edwin)
Attachment #8565788 - Flags: approval-mozilla-beta?
Comment on attachment 8565788 [details] [diff] [review]

Video playback is a current priority. This fix has been on m-c/m-a for two weeks. Let's take the fix in Beta 4. Beta+
Attachment #8565788 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
We could not reproduce the original issue. Exploratory testing for Audio and Video on Firefox 37 Beta 4 revealed no new issues. 

Removing the "qe-verify" flag as it seems there's nothing more for us to do here.
Flags: qe-verify+
dveditz, why is this status-firefox-esr31:affected?

This was a regression from bug 981869, whose patch AFAICT hasn't landed on ESR 31.
Flags: needinfo?(dveditz)
(FWIW: I can't reproduce this in latest ESR31 release (31.5.3), but don't read too much into that, because I also can't reproduce with the Nightly that I used to file this bug in comment 0. So I suspect that means I got an update to the gstreamer thing that we blacklisted in the regressing bug.

Still, I don't see any reason to suspect ESR is affected, per comment 17.)
We will need Daniel's weigh in here.
I suppose bug 981869 comment 42 answers my question in comment 17 here. (Looks like we'll be backporting bug 981869 to esr31, which means we need to backport this bug's patch as well.)

needinfo=edwin for the uplift request (I guess)
Flags: needinfo?(dveditz) → needinfo?(edwin)
(In reply to Daniel Holbert [:dholbert] from comment #17)
> dveditz, why is this status-firefox-esr31:affected?
> This was a regression from bug 981869, whose patch AFAICT hasn't landed on
> ESR 31.

bug 981869 was tracked for ESR31 and I wanted to make sure this one didn't get missed along with it.
Comment on attachment 8565788 [details] [diff] [review]

Approval request comment in comment 13
Flags: needinfo?(edwin)
Attachment #8565788 - Flags: approval-mozilla-esr31?
Attachment #8565788 - Flags: approval-mozilla-esr31? → approval-mozilla-esr31+
I could reproduce using Nightly 38.0a1 2015-02-16 on a single Ubuntu 14.04 32-bit machine (out of for) and only with the vimeo link from comment 6.
The vimeo video is correctly played on Firefox 37RC, latest Dev Edition 38.0a2 and 31.6.0 ESR.

Based on this and on comment 18, I'm marking this as verified. Also there were no new issues on this.
Blocks: 1154045
You need to log in before you can comment on or make changes to this bug.