Closed Bug 1279973 Opened 8 years ago Closed 8 years ago
Webm Video Does Not Render Correctly in 10
8.28 MB, application/octet-stream
4.22 MB, application/octet-stream
3.89 KB, patch
|Details | Diff | Splinter Review|
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.
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
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?
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 <firstname.lastname@example.org> 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?
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.
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.
Cannot reproduce on Big Buck Bunny videos, can reproduce on Elephants Dreams video if I seek forward (see the attached 1279973_ed.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://email@example.com/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?
This patch fixes the issue here, all videos that I've tried renders correctly on try-build.
(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 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 firstname.lastname@example.org: 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).
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 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 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.
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.
You need to log in before you can comment on or make changes to this bug.