[Tracking Requested - why for this release]: Regression STR: 1. Open this URL - http://edition.cnn.com/2017/03/07/vr/manila-philippines-drug-war/index.html 2. Enjoy the hang 3. If not, start seeking the movie, to get the hang. "Speedy" Regression window (mozilla-inbound) Good: https://hg.mozilla.org/integration/mozilla-inbound/rev/4e90c48f26179dc59150ae002a46666014fd3cbc Bad: https://hg.mozilla.org/integration/mozilla-inbound/rev/835425e189a5b19703e4f2202e3d96f9629da41f Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4e90c48f26179dc59150ae002a46666014fd3cbc&tochange=835425e189a5b19703e4f2202e3d96f9629da41f Probably caused by: 0d4603ebe97e Bas Schouten — Bug 1340398 - Part 3: Use NV12 format by default. r=mattwoodrow be80dc74a965 Bas Schouten — Bug 1340398 - Part 2: Support NV12 texture hosts in CompositorD3D11. r=mattwoodrow b94a413fe46a Bas Schouten — Bug 1340398 - Part 1: Allow SyncObject usage for different devices. r=mattwoodrow Less likely caused by: f553a59096ad David Anderson — Enable restarting the GPU process when it dies. (bug 1337131, r=milan)

I also have this happen on some videos at msn.com. I usually get a not responding message in the caption bar. Fx hangs for a little bit while the audio plays. Eventually the video returns.

I also have this happen on some videos at msn.com. I usually get a not responding message in the caption bar. Fx hangs for a little bit while the audio plays. Eventually the video returns. Example: http://www.msn.com/en-us/money/personalfinance/which-income-class-are-you-in/ar-AAk13MO?li=BBnb7Kz

Crash report when viewing http://edition.cnn.com/2017/03/07/vr/manila-philippines-drug-war/index.html https://crash-stats.mozilla.com/report/index/2ba98e5f-4218-4a40-a2d0-7c7402170309

Tracking 55+ for this visible video regression.

Could you try setting the pref: 'media.windows-media-foundation.use-sync-texture' to false, restart and confirm that fixes the issue? I'm looking into this.

Another crash playing http://www.cnn.com/videos/cnnmoney/2017/03/08/steve-mcqueen-famous-bullitt-mustang-allegedly-found-pkg.cnn/video/playlists/stories-worth-watching/ Crash dump: https://crash-stats.mozilla.com/report/index/ec3dbbe4-2868-478a-b768-cb98f2170309#tab-modules I'll try the pref now.

I didn't have the pref you mentioned so I added it as False. I got messages on the video that the music was playing and something about captions. The video did not play. There is a similar pref called media.windows-media-foundation.allow-d3d11-dxva. It was true so I set it to false. Seems the videos are playing now. I still need to test more.

Bas... Don't know if this is related to whatever busted the videos but using uBlock Origin to block ads and using the EasyList subscription causes videos on MSN to take from 30-45 seconds to play. During that time I get a spinner. When I disable EasyList filters the video plays right away. I never had this before. I posted this problem on the EasyList forum. I'm wondering if whatever the 'bad' patch did is also affecting ad blocking.

Forget the uBlock thing I mentioned. The cause was another add-on which happens to use webextensions I got from the google store.

Setting media.windows-media-foundation.allow-d3d11-dxva to false definitely fixes my video problems.

I'm getting this with today's build on twitter and imgur when there's html5 video. Setting media.windows-media-foundation.allow-d3d11-dxva to false fixes it.

(In reply to Gary [:streetwolf] from comment #7) > I didn't have the pref you mentioned so I added it as False. I got messages > on the video that the music was playing and something about captions. The > video did not play. Hrm, did you restart after setting the pref to false?

(In reply to Gary [:streetwolf] from comment #10) > Setting media.windows-media-foundation.allow-d3d11-dxva to false definitely > fixes my video problems. Yeah, that just bypasses all this code :-)

(In reply to Bas Schouten (:bas.schouten) from comment #12) > (In reply to Gary [:streetwolf] from comment #7) > > I didn't have the pref you mentioned so I added it as False. I got messages > > on the video that the music was playing and something about captions. The > > video did not play. > > Hrm, did you restart after setting the pref to false? Yes, I restarted Fx.

Hrm, could you post your about:graphics? Everything seems fine on my machine at least on the first two links.

Here's my complete about:support.

FYI.... I've tested with a new profile and had the same problems. They happened even quicker. Have you tried to move the slider ahead? This will usually cause Fx to stall. After around 15-30 seconds the video will play. The audio still plays when the video doesn't.

My guess right now is that this is somehow AMD specific. In at least one of the crashes we see another thread blocked on -releasing- the KeyedMutex, needless to say that should never really be an issue, my guess is that it's waiting on an internal D3D11 thread to finish rendering, and that, for some reason isn't happening.

(In reply to Bas Schouten (:bas.schouten) from comment #18) > My guess right now is that this is somehow AMD specific. In at least one of > the crashes we see another thread blocked on -releasing- the KeyedMutex, > needless to say that should never really be an issue, my guess is that it's > waiting on an internal D3D11 thread to finish rendering, and that, for some > reason isn't happening. Can you reach out to AMD about this?

I actually bet this has to do with Device re-use on AMD, I have a build which I'm almost certain will fix the issue for you, let me give you that for informative reasons, then I'll look into a 'proper' fix.

(In reply to Bas Schouten (:bas.schouten) from comment #20) > I actually bet this has to do with Device re-use on AMD, I have a build > which I'm almost certain will fix the issue for you, let me give you that > for informative reasons, then I'll look into a 'proper' fix. Whatever you need from me I'll be happy to do it.

Could you try the build at: https://archive.mozilla.org/pub/firefox/try-builds/bschouten@mozilla.com-bb4dfa94b8287864c5f67cb5bb556f7dcc6fb77e/ (once it's done) with a clean profile? Let me know if that plays smoothly.

Will do.

Tried out your fix from your try-builds link and so far videos that previously had problems now work fine. Waiting for it to make it to inbound. Thanks Bas.

Forgot to mention that I set 'media.windows-media-foundation.allow-d3d11-dxva' back to true while testing.

(In reply to Gary [:streetwolf] from comment #25) > Forgot to mention that I set > 'media.windows-media-foundation.allow-d3d11-dxva' back to true while testing. I did say clean profile ;-). But yeah, as long as you made sure it's all set back :-).

Just tried a new profile and it also works.

(In reply to Gary [:streetwolf] from comment #27) > Just tried a new profile and it also works. Thanks! That's good news, I think we'll be okay with this patch then.

Comment on attachment 8846225 [details] Bug 1345814: Don't use mutices when the decoding device is the compositor device anyway. https://reviewboard.mozilla.org/r/119322/#review121316

Pushed by bschouten@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/46090632bad3 Don't use mutices when the decoding device is the compositor device anyway. r=mattwoodrow

Backout by archaeopteryx@coole-files.de: https://hg.mozilla.org/integration/mozilla-inbound/rev/533ce084c0d4 Backed out changeset 46090632bad3 for failing reftests on Windows 8 x64 with e10s enabled, e.g. webgl-capturestream-test.html?preserve. r=backout n a CLOSED TREE

Backed out for failing reftests on Windows 8 x64 with e10s enabled, e.g. webgl-capturestream-test.html?preserve https://hg.mozilla.org/integration/mozilla-inbound/rev/533ce084c0d46a7529fd9a37ad99db43bfb206b9 Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=46090632bad356411c602147cadedb7822e3152e&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=83384823&repo=mozilla-inbound > 06:37:49 INFO - REFTEST TEST-UNEXPECTED-FAIL | file:///C:/slave/test/build/tests/reftest/tests/dom/canvas/test/reftest/webgl-capturestream-test.html?preserve == file:///C:/slave/test/build/tests/reftest/tests/dom/canvas/test/reftest/wrapper.html?green.png | image comparison, max difference: 255, number of differing pixels: 65536

Pushed by bschouten@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/8afe7f683eaa Don't use mutices when the decoding device is the compositor device anyway. r=mattwoodrow

Can you confirm the issue is fixed on a nightly with a fresh profile? This is a top 10 crash so I want to be absolutely sure :).

(In reply to Bas Schouten (:bas.schouten) from comment #37) > Can you confirm the issue is fixed on a nightly with a fresh profile? This > is a top 10 crash so I want to be absolutely sure :). Everything looks great. No crashes at all with a new profile. Thanks Bas.

Thanks, looks fix, so I'm marking this as VERIFIED.