<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Reporter

Comment 2

•

7 years ago

All HTML5 videos, yes. Youtube etc. Not sure I've seen it on Twitch though - could be video framerate vs vsync rate related FWIW some native video player software has had the same problem on Nvidia's drivers when Windows' DWM is involved, so it's possible this is a driver issue that FF is hitting now due to video playback or compositor changes

Flags: needinfo?(kg)

Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail

Reporter

Comment 3

•

7 years ago

The user-visible glitch behavior is the same as this https://bugzilla.mozilla.org/show_bug.cgi?id=1233815 but I have no idea whether the cause would be the same.

Comment 4

•

7 years ago

Upping the priority. :kael, would you be able to capture a video of this happening? If you're able to find if this is a regression via moz-regression[0], that would help a lot. [0]: https://mozilla.github.io/mozregression/

Flags: needinfo?(kg)

Priority: P3 → P2

Reporter

Comment 5

•

7 years ago

Mozregression will be difficult, but I'll see if I can come up with a way to reliably reproduce it. I'm setting up a 144hz monitor today so I'll try to experiment with different display refresh rates to see if that has an impact.

Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail

Reporter

Comment 6

•

7 years ago

Attached video Video of playback glitch — Details

I managed to capture it using my cell phone's slow motion mode. Unfortunately, it produces 240hz videos so the video plays back at normal speed... if you single step through the frames using a player like MPC-HC you can clearly see what's going on, but it's also just visible if you watch it at 1:1 speed because the motion seems to jump backwards and then forwards. The video being viewed was a 60hz youtube video (though as mentioned before, it happens pretty much everywhere intermittently) - https://www.youtube.com/watch?v=j57PfkWJypE.

Flags: needinfo?(kg)

Comment 7

•

7 years ago

Thanks for the video. Could you let me know if you still see the issue with hardware acceleration disabled (https://support.mozilla.org/en-US/kb/performance-settings)? As with bug 1233815, and based on comment 2 I'm wondering if this is somewhere in the gfx pipeline.

Flags: needinfo?(kg)

Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail

Comment 8

•

7 years ago

Matt, are you aware of any issues in gfx similar to this one/that may be causing this?

Flags: needinfo?(matt.woodrow)

Comment 9

•

7 years ago

I am not. We've had bugs like this in the past, but they have usually been on the decoder side. Gfx just gets a list of timestamped frames (sorted oldest to newest), and then displays the first one with a timestamp later than the current time. If the input frames are as expected, it seems unlikely that gfx would get the order wrong. Any theories jya?

Flags: needinfo?(matt.woodrow) → needinfo?(jyavenard)

Comment 10

•

7 years ago

What's weird is that it affects both YouTube (which considering the OP info would be using vp9) and twitter which is h264. Now, vp9 doesn't have a concept of frame order like h264 would. So while you could expect out of order frames being composited with h264, it just can't happen with vp9 decoder. So either the content was wrong, or something is amiss in the compositing/drivers. We haven't hard report like that earier. I have an nvidia 1050i (dell xps 15) and a 1080Ti (desktop), I don't experience this behaviour.. so no idea..

Flags: needinfo?(jyavenard)

Comment 11

•

7 years ago

Matt, the same reporter created a bug that was duped to bug 1236112. You had implemented a fix for D3D9 there. Could it be the same issue with D3D11?

Flags: needinfo?(matt.woodrow)

Comment 12

•

7 years ago

You know, you might be right! We did have the same issue with D3D11, and bug 1257013 fixed it. I'm fairly sure that bug 1340359 regressed it again though :(

Flags: needinfo?(matt.woodrow)

Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail

Reporter

Comment 13

•

7 years ago

fwiw, the reason this may be hard to reproduce for other people is that i'm running two 4k panels at 60hz, so the actual time spent decoding, scaling and compositing frames is probably a lot longer than it is on other people's test machines. That would make it easier for something to lose a race if synchronization is wrong.

Comment 14

•

7 years ago

I'm able to reproduce this on a setup with two monitors (1080, 4K) with a GeForce 1070. If I run something graphically intensive on the 4K monitor (GPU benchmark, GPU intensive game) and play back a video in Firefox on the second I see the issue in the video. However, the issue is rare/doesn't appear to happen in fresh profiles, which has foiled my attempts to bisect thus far. The machine I'm using to test is not one of my normal dev machines, but should I get another moment I'll see if I can isolate what in my default profile is causing the issue and/or bisect with that profile.

Comment 15

•

7 years ago

(In reply to Bryce Seager van Dyk (:bryce) from comment #14) > I'm able to reproduce this on a setup with two monitors (1080, 4K) with a > GeForce 1070. If I run something graphically intensive on the 4K monitor > (GPU benchmark, GPU intensive game) and play back a video in Firefox on the > second I see the issue in the video. > > However, the issue is rare/doesn't appear to happen in fresh profiles, which > has foiled my attempts to bisect thus far. The machine I'm using to test is > not one of my normal dev machines, but should I get another moment I'll see > if I can isolate what in my default profile is causing the issue and/or > bisect with that profile. The first step might be to add back the code that was removed in bug 1340359, and have a pref deciding if we use it or not. Could just do a try run with that, and see if :kael can still reproduce the issue. Assuming that this is the issue then I think the best long term fix is to initialize an ID3D11Query object waiting for the copy to be done, and hold a reference to the decoder's texture (so that it doesn't get returned for reuse). When later frames are about to be decoded, we can look use the query objects to check if any of our earlier frames are now complete, and return them to the decoder (drop the ref) if so. The decoder will hang if it ever runs out of textures, so we want to make sure our list of in-progress frames never gets too long. I think there's usually only 3 total frames in play, but there might be a way to query/configure this. If we do get into the state where we're still holding all the textures and we're about to request a new frame to be decoded, then we probably want to spin-lock to wait for the oldest one to be done. We might need a timeout here (bug 1257013 had a comment about them sometimes not finishing).

Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail

Reporter

Comment 16

•

7 years ago

I still see this intermittently, but it's not as bad as it used to be. Maybe on the order of 3-40 out of order frames per minute. I just tried switching over to WebRender and haven't seen it yet, so fingers crossed. Historically other video compositors have had this issue (like madVR for directshow-based players) and when I examined those with GPUView it was clearly an NVIDIA driver issue - sometimes it seemed like DWM was presenting frames out of order. Does FF normally use DWM to present video frames?

Flags: needinfo?(kg)

Comment 18

•

6 years ago

Following up on this as we're seeing further reports and I still repro on my dual monitor setup. I tried as best I could to add the code mentioned in comment 11 back in, and was still seeing the issue. However, as this is not my area of expertise, I wonder if someone else may be better suited to help debug this. Matt, would you be able to help find someone to look at this, or help me pass NI to someone who could?

Flags: needinfo?(matt.woodrow)

Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail

Comment 19

•

6 years ago

Can you attach the patch for the test you did?

I probably won't have time to dig into this myself in the near future.

Comment 20

•

6 years ago

Attached file Patch attempting to revert to old behaviour — Details

This was my attempt. I can bring it forward and attempt to modify further if it would aid in debugging.

Comment 21

•

6 years ago

If you set the pref media.wmf.low-latency.force-disabled to true.

do you still see the problem?

Flags: needinfo?(kg)

Updated

•

6 years ago

Status: NEW → RESOLVED

Closed: 6 years ago

Flags: needinfo?(bvandyk)

Resolution: --- → FIXED

[1] https://searchfox.org/mozilla-central/rev/06bd14ced96f25ff1dbd5352cb985fc0fa12a64e/gfx/thebes/DeviceManagerDx.cpp#604

Comment 22

•

6 years ago

That patch looks about what I expected. So it works the same as without the patch?

It appears that we'd still be getting textures with an associated KeyedMutex, but we're not locking it in that new path (AutoTextureLock is only in the old path). That seems like it would cause us to fail to render entirely though.

gfx.direct3d11.enable-debug-layer=true (plus VisualStudio attached) would give you any errors reported, and using the debugger to make sure we're actually running that path would be valuable.

gfx.direct3d11.break-on-error=true will make the errors even more forceful (and filters out some known errors from the compositor [1]), but if it's possible that the filter list is out of date and we'd crash on unrelated problems (fixing or filtering those would be good!).

Flags: needinfo?(matt.woodrow)

Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail

Comment 23

•

6 years ago

(In reply to Jean-Yves Avenard [:jya] from comment #21)

If you set the pref media.wmf.low-latency.force-disabled to true.

do you still see the problem?

Rechecking with changing of certain prefs (confirming I restarted between pref flips):

media.wmf.low-latency.force-disabled = true: problem still happens
gfx.webrender.enabled = true: problem does not seem to happen

(In reply to Matt Woodrow (:mattwoodrow) from comment #22)

That patch looks about what I expected. So it works the same as without the patch?

It's been awhile, but I'm confident I still saw the issue with that patch applied. I will try to bring the patch forward and confirm that to be so.

I'll take a look at testing with those other prefs also.

Reopening as close looks accidental.

Status: RESOLVED → REOPENED

Flags: needinfo?(bvandyk)

Resolution: FIXED → ---