1279973 - Webm Video Does Not Render Correctly in 10.12 Sierra

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Will Stamper]

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.

Comment 1

[Will Stamper]

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.

Comment 2

[Will Stamper]

Perhaps worth noting that VLC, Chrome, and Safari all play back the videos correctly.

Comment 3

[ojab]

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

Comment 4

[Jean-Yves Avenard [:jya]]

can't be decoding as there's nothing OS related when doing webm.. attempting gfx

Comment 5

[PointlessOne]

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.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

Will, any chance of a regression range using mozregression?

Comment 7

[Will Stamper]

This issue appears to be resolved on my machine with 49.0a2 (6-28-16) https://hg.mozilla.org/releases/mozilla-aurora/rev/f20f82876561686c4f8a619a0e1baa9f58261e0f

Comment 8

[ojab]

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

Comment 9

[ojab]

$ hg bisect --good
The first bad revision is:
changeset:   285570:e6d0c56847ce
tag:         qparent
user:        Nicolas Silva <[e-mail]>
date:        Thu Feb 25 14:15:40 2016 +0100
summary:     Bug 1249273 - Lazily prepare TextureSources and recycle them when possible in ImageHost. r=sotaro

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

:nical, can you reproduce this locally?

Comment 11

[Nicolas Silva [:nical]]

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.

Comment 12

[Nicolas Silva [:nical]]

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.

Comment 13

[ojab]

Attachment: 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)

Comment 14

[ojab]

Attachment: 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).

Comment 15

[Nicolas Silva [:nical]]

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.

Comment 16

[Nicolas Silva [:nical]]

Attachment: Check the format and size of all (sub) TextureSources before recycling them.

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.

Comment 17

[Nicolas Silva [:nical]]

Build ready. ojab, could you grab this firefox build http://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-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?

Comment 18

[ojab]

This patch fixes the issue here, all videos that I've tried renders correctly on try-build.

Comment 19

[Nicolas Silva [:nical]]

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

Comment 20

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8766760 [details] [diff] [review]
Check the format and size of all (sub) TextureSources before recycling them.

Looks good!

Comment 21

[Pulsebot]

Pushed by [e-mail]:
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

Comment 22

[Nicolas Silva [:nical]]

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

Comment 23

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/15e7cce04da4

Comment 24

[ovidiu boca[:Ovidiu]]

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.

Comment 25

[Milan Sreckovic [:milan] (needinfo for best results)]

Let's try for the uplift then.

Comment 26

[Nicolas Silva [:nical]]

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.

Comment 27

[Gerry Chang [:gchang]]

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.

Comment 28

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/ef8dd8e8237a

Comment 29

[Ciprian Georgiu, Desktop QA]

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.