Closed Bug 1279973 Opened 5 years ago Closed 5 years ago

Webm Video Does Not Render Correctly in 10.12 Sierra

Categories

(Core :: Graphics, defect)

47 Branch
Unspecified
macOS
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla50
Tracking Status
firefox47 --- wontfix
firefox48 --- wontfix
firefox49 --- verified
firefox50 --- verified

People

(Reporter: epmatsw, Assigned: nical)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [gfx-noted])

Attachments

(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160613004107

Steps to reproduce:

Open any webm video (most of mine have been opened via Reddit and are hosted on Imgur). Example video: https://i.imgur.com/3UPHMdr.webm


Actual results:

Video renders first frame, followed by some ghosting of the rest of the video.


Expected results:

Video plays correctly.
OS: Unspecified → Mac OS X
Info from about:support:
Features
Compositing	OpenGL
Asynchronous Pan/Zoom	wheel input enabled
WebGL Renderer	ATI Technologies Inc. -- AMD Radeon R9 M370X OpenGL Engine
Hardware H264 Decoding	Yes
GPU #1
Active	Yes
Vendor ID	0x8086
Device ID	0x0d26
Diagnostics
AzureCanvasAccelerated	0
AzureCanvasBackend	skia
AzureContentBackend	skia
AzureFallbackCanvasBackend	none

Hmm. Experimenting a bit more, this is only happening when the integrated graphics (Intel Iris Pro) rather than dedicated are in use. Probably a driver bug, but maybe worth looking at.
Perhaps worth noting that VLC, Chrome, and Safari all play back the videos correctly.
Same here on intel graphics

Features
Compositing	OpenGL
Asynchronous Pan/Zoom	wheel input enabled
WebGL Renderer	Intel Inc. -- Intel Iris Pro OpenGL Engine
Hardware H264 Decoding	Yes
GPU #1
Active	Yes
Vendor ID	0x8086
Device ID	0x0d26
Diagnostics
AzureCanvasAccelerated	0
AzureCanvasBackend	skia
AzureContentBackend	skia
AzureFallbackCanvasBackend	none
Component: Untriaged → Audio/Video
Product: Firefox → Core
Component: Audio/Video → Audio/Video: Playback
can't be decoding as there's nothing OS related when doing webm.. attempting gfx
Component: Audio/Video: Playback → Graphics
The link from comment #1 plays fine on beta.

Application Basics
------------------

Name: Firefox
Version: 48.0b1
Build ID: 20160606200529
Update Channel: beta
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:48.0) Gecko/20100101 Firefox/48.0
OS: Darwin 16.0.0 x86-64
Multiprocess Windows: 0/3 (Disabled by add-ons)
Safe Mode: false

Graphics
--------

Features
Compositing: Basic
Asynchronous Pan/Zoom: none
Hardware H264 Decoding: No
GPU #1
Active: Yes
Vendor ID: 0x8086
Device ID: 0x0046

Diagnostics
AzureCanvasAccelerated: 0
AzureCanvasBackend: skia
AzureContentBackend: skia
AzureFallbackCanvasBackend: none
webglRendererMessage: Blocked for your graphics driver version.
Will, any chance of a regression range using mozregression?
Flags: needinfo?(epmatsw)
Whiteboard: [gfx-noted]
This issue appears to be resolved on my machine with 49.0a2 (6-28-16) https://hg.mozilla.org/releases/mozilla-aurora/rev/f20f82876561686c4f8a619a0e1baa9f58261e0f
Still reproducible here on latest nightly.
Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
61:38.85 INFO: Narrowed inbound regression window from [7bcbdd73, aa348994] (3 revisions) to [3a55e7c4, aa348994] (2 revisions) (~1 steps left)
61:38.85 INFO: Oh noes, no (more) inbound revisions :(
61:38.85 INFO: Last good revision: 3a55e7c48a530eab188db1e011ede8498c2190fc
61:38.85 INFO: First bad revision: aa348994df48dd1ab2216b9f13473c6a6049ec9f
61:38.85 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3a55e7c48a530eab188db1e011ede8498c2190fc&tochange=aa348994df48dd1ab2216b9f13473c6a6049ec9f
$ hg bisect --good
The first bad revision is:
changeset:   285570:e6d0c56847ce
tag:         qparent
user:        Nicolas Silva <nsilva@mozilla.com>
date:        Thu Feb 25 14:15:40 2016 +0100
summary:     Bug 1249273 - Lazily prepare TextureSources and recycle them when possible in ImageHost. r=sotaro
:nical, can you reproduce this locally?
Assignee: nobody → nical.bugzilla
Blocks: 1249273
Flags: needinfo?(epmatsw) → needinfo?(nical.bugzilla)
Version: 49 Branch → 47 Branch
I haven't managed to reproduce it on the two linux computers I have (with gl layers enabled to get closer to the mac's configuration) and on android, testing release and nightly. I am also asking people with macs in the Paris office to test (so far no repro).

This regression range makes a lot of sense since the patch affects video compositing, however it doesn't try to do anything fancy (it's mostly about uploading to already existing gl textures instead of creating new ones) so I am surprised that the driver chokes on it.
I'll try to put some extra logging in place to see if something shows up.
Flags: needinfo?(nical.bugzilla)
imgur seems to be serving different video formats depending on a bunch of things (I suspect user agent and the url itself), with variations of the link in comment zero I get mp4 and gifv videos.

ojab, could you try to play the video on this page http://www.webmfiles.org/demo-files/ (which will be webm for sure)? Also, could you right-click the video and select "save video as" with the imgur link from cmment 0 to see what the actual video type is in your case (you don't have to download the video, just look at the file extension)? It would be interested to see if there is a correlation between formats that work (if any) and formats that don't work.
Flags: needinfo?(ojab)
Attached file 1279973_ed.mov
Cannot reproduce on Big Buck Bunny videos, can reproduce on Elephants Dreams video if I seek forward (see the attached 1279973_ed.mov)
Flags: needinfo?(ojab)
Attached file 1279973_imgur.mov
If you'll download https://i.imgur.com/3UPHMdr.webm using curl/wget, you'll get a webm version which is the far better testcase (always reproducible from the start, see 1279973_imgur.mov).
These screen recordings are interesting. It looks like some of the (yuv) planes are working (kinda) and not some others within the same frame. We make assumptions about the the format of the yuv data we receive in the compositor and in particular I suspect we are not handling very well the hypothetical case where the uv planes change size during playback. Looks like we only check that the Y plane has kept the same format+size and that the U and V planes are still present without checking their formats and size. It could be that we are trying to upload some data with an incorrect format to a gl texture and that some gl driver are stricter than others about that.

I wrote a patch that more thoroughly checks the format and size for each plane before recycling textures https://treeherder.mozilla.org/#/jobs?repo=try&revision=00dba0a55d51806de8bc4d6d42a71aeb56dfacf5 I'll provide a download link when the build is done (nobody reproduced the bug in the office). Hopefully this is what's causing the problem.
If it doesn't turn out to fix the bug we should still take this patch, it makes the recycling of TextureSource objects more robust against edge cases.
Attachment #8766760 - Flags: review?(sotaro.ikeda.g)
Build ready. ojab, could you grab this firefox build http://archive.mozilla.org/pub/firefox/try-builds/nsilva@mozilla.com-00dba0a55d51806de8bc4d6d42a71aeb56dfacf5/try-macosx64/firefox-50.0a1.en-US.mac.dmg and use it to go through the various failing videos again and see if it fixes the issue?
Flags: needinfo?(ojab)
This patch fixes the issue here, all videos that I've tried renders correctly on try-build.
Flags: needinfo?(ojab)
(In reply to ojab from comment #18)
> This patch fixes the issue here, all videos that I've tried renders
> correctly on try-build.

\o/ excellent! Thanks a lot for testing.
Blocks: sierra
Comment on attachment 8766760 [details] [diff] [review]
Check the format and size of all (sub) TextureSources before recycling them.

Looks good!
Attachment #8766760 - Flags: review?(sotaro.ikeda.g) → review+
Pushed by nsilva@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/15e7cce04da4
Better handle video frames with varrying/inconsistent plane sizes and formats in the compositor. r=sotaro
Let's give this patch a day or two in central and uplift it as far as we can. I don't think it is worth making a release for, but it is a simple patch that fixes video playback for some users (no idea what volume).
https://hg.mozilla.org/mozilla-central/rev/15e7cce04da4
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID 	20160718030454

Tested on Mac 10.12 with FF 50.0a1 and I can't reproduce the issue following the steps from description.
Status: RESOLVED → VERIFIED
Let's try for the uplift then.
Flags: needinfo?(nical.bugzilla)
Comment on attachment 8766760 [details] [diff] [review]
Check the format and size of all (sub) TextureSources before recycling them.

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: Some users can't watch some videos (seems to depend on drivers and how the video itself is encoded).
[Describe test coverage new/current, TreeHerder]:
[Risks and why]: Low, rather simple, has baked in nightly for a while.
[String/UUID change made/needed]: None.
Flags: needinfo?(nical.bugzilla)
Attachment #8766760 - Flags: approval-mozilla-beta?
Attachment #8766760 - Flags: approval-mozilla-aurora?
Comment on attachment 8766760 [details] [diff] [review]
Check the format and size of all (sub) TextureSources before recycling them.

Review of attachment 8766760 [details] [diff] [review]:
-----------------------------------------------------------------

49 is going to be released in mid- Sep and Sierra is probably not released at that time. Let's let it ride the train on 49 and not fix in 48 to mitigate the risks on the release.
Attachment #8766760 - Flags: approval-mozilla-beta?
Attachment #8766760 - Flags: approval-mozilla-beta-
Attachment #8766760 - Flags: approval-mozilla-aurora?
Attachment #8766760 - Flags: approval-mozilla-aurora+
Flags: qe-verify+
I didn't managed to reproduce this issue on an older Nightly build from 2016-06-13 because macOS 10.12 Sierra encounter some problems opening older builds.

I verified this issue with 49.0-build2 on different sites with WebM content and also with the link provided in Str and comment 12. No rendering or lagging problems were seen on those websites.

Based on my investigation/verification, I will mark this issue verified on Firefox 49.0-build2(2016-09-07)running macOS 10.12 Sierra and closing this bug as verified fixed.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.