Closed Bug 1640607 Opened 1 year ago Closed 8 months ago

360 Video stutters on 4k monitor

Categories

(Core :: Graphics, defect, P1)

78 Branch
Unspecified
Windows
defect

Tracking

()

VERIFIED FIXED
86 Branch
Tracking Status
firefox78 --- wontfix
firefox85 --- wontfix
firefox86 --- verified

People

(Reporter: raluca.popovici, Assigned: jgilbert)

References

(Regressed 1 open bug)

Details

(Keywords: perf, perf-alert)

Attachments

(3 files)

Attached file aboutsupport (2).txt

Note:
360 Video stutters on 4k monitor(resolution: 20560x2048). The same problem happens with webrender on and off.

Affected versions:
Nightly v78.0a1

Affected platforms:
Windows 10

Steps to reproduce:

  1. Open Nightly 78.0a1
  2. Go to https://www.youtube.com/watch?v=JtYa0rb_jGQ&list=FLQDozCIKe1FJdThFLX-YWLg&index=4
  3. Click on Full-screen button
  4. Move the camera up/down/right side/left side

Expected result
360 Video should be properly displayed.

Actual result
360 Video stutters on 4k monitor

Severity: -- → S2

S1 or S2 bugs need an assignee - could you find someone for this bug?

Flags: needinfo?(bvandyk)

Could you gather a profile of the issue taking place using the Firefox profiler and the Media preset, then share that profile run and link it on this bug?

Flags: needinfo?(rpopovici)
Assignee: nobody → bvandyk
Flags: needinfo?(bvandyk)

I will try on Tuesday when I have access to the 4k monitor and I will let you know.

Flags: needinfo?(rpopovici)

Hi Bryce,
This is the performance profile of this issue: https://share.firefox.dev/3h4zUsx and I will attach the zip in case the link doesn't work for you.

Flags: needinfo?(bvandyk)

Thanks for that. Could you try installing Firefox Nightly and capturing another profile using the 'media' preset? This should give us richer info to try and debug this.

Flags: needinfo?(bvandyk) → needinfo?(rpopovici)

Here is the link of a profile using the 'media' preset from Nightly 79.0a1 (2020-06-09): https://share.firefox.dev/2UxeF8Z

Flags: needinfo?(rpopovici) → needinfo?(bvandyk)

Sorry for the delayed response. That profile run looks fairly short, just over a second, and I'm not sure if some of the values I'm seeing are due to performance or the limited amount of data. Would it be possible to gather a longer run with the media preset?

Flags: needinfo?(bvandyk) → needinfo?(raluca.popovici)
Priority: -- → P3

Sorry for the delayed response. I didn't have access to the 4k monitor. Here is the link of a profile using the 'media' preset from Nightly 83.0a1 (2020-10-12): https://share.firefox.dev/3nKRVzd

Flags: needinfo?(raluca.popovici) → needinfo?(bvandyk)

That profile is missing a number of the threads used of media. It looks like it should be tracking them based on the settings -- so I'm not sure what's going on. Could you try recording another one? MediaDecoderStateMachine is one of the threads it would be useful to see (you can see it in the older profile but not in the newer one).

Flags: needinfo?(bvandyk) → needinfo?(raluca.popovici)

Hi,
Here is the link of a profile using the 'media' preset and MediaDecoderStateMachine threads: https://share.firefox.dev/35yHab5. I hope it's useful for you this time.

Flags: needinfo?(raluca.popovici) → needinfo?(bvandyk)

Thanks for the updated profile. Looking at the markers on the media decoder state machine thread they look pretty good. Our PlayVideo and PushVideo markers don't look to have major discontinuities in the timestamps on the data, though we do appear to have some frame drops in decode.

I see webcontent spending a fair amount of time in layers. I'm going to move this to gfx so someone more familiar with gfx can comment on that part of the profile. Feel free to move back to media if it's non-conclusive.

Assignee: bvandyk → nobody
Severity: S2 → --
Component: Audio/Video: Playback → Graphics: Layers
Flags: needinfo?(bvandyk)
Priority: P3 → --

Jeff (M or G), can you take a look? I'm not sure what to make of this. The user is on WebRender, but I don't know that I see distinct bottlenecks in the profiles. This could also be a WebGL issue?

Severity: -- → S3
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(jgilbert)
Keywords: perf
OS: Unspecified → Windows
Priority: -- → P3
Component: Graphics: Layers → Graphics

This is definitely OOP WebGL requiring a readback (and a copy into shmem) to draw video, where in-process WebGL previously just copied GPU memory.

Same issue as bug 1670542, not sure if Jeff wants to dup to that or not.

Flags: needinfo?(jmuizelaar)
Assignee: nobody → jgilbert
Flags: needinfo?(jgilbert)
Priority: P3 → P1
Pushed by jgilbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6149f5b15c5e
Send SurfaceDescriptors for GPU blitting for video-to-webgl. r=lsalzman
Pushed by jgilbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4cff94ca9818
Send SurfaceDescriptors for GPU blitting for video-to-webgl. r=lsalzman
Regressions: 1686750
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
Flags: needinfo?(jgilbert)

Reproduced in Firefox 85.0b9 (64-bit).
I have verified that the issue is no longer reproducible on the latest Firefox Nightly 86.0a1 (2021-01-17) (64-bit) using Windows 10 and a 4k monitor.

No longer regressions: 1687231
Regressed by: 1687231
No longer regressed by: 1687231
Regressions: 1687231

Updating bug status as well, based on previous comment.

Status: RESOLVED → VERIFIED

== Change summary for alert #28484 (as of Mon, 18 Jan 2021 12:05:16 GMT) ==

Improvements:

Ratio Suite Test Platform Options Absolute values (old vs new)
92% glvideo Mean tick time across 100 ticks: windows10-64-ref-hw-2017 e10s stylo webgl-ipc 49.93 -> 4.12
87% glvideo Mean tick time across 100 ticks: windows10-64-qr e10s stylo webgl-ipc webrender 31.81 -> 4.26
87% glvideo Mean tick time across 100 ticks: windows10-64-shippable e10s stylo 31.29 -> 4.20
87% glvideo Mean tick time across 100 ticks: windows10-64 e10s stylo webgl-ipc 31.25 -> 4.20
87% glvideo Mean tick time across 100 ticks: windows10-64-shippable e10s stylo webgl-ipc 30.91 -> 4.17
86% glvideo Mean tick time across 100 ticks: windows10-64-shippable-qr e10s stylo webgl-ipc webrender 31.13 -> 4.23
86% glvideo Mean tick time across 100 ticks: windows10-64-shippable-qr e10s stylo webrender 30.86 -> 4.21
86% glvideo Mean tick time across 100 ticks: windows10-64-qr e10s stylo webgl-ipc webrender 30.62 -> 4.22
79% glvideo Mean tick time across 100 ticks: windows10-64-shippable-qr e10s stylo webrender-sw 19.85 -> 4.21
54% glvideo Mean tick time across 100 ticks: macosx1014-64-shippable-qr e10s stylo webrender-sw 33.61 -> 15.63
51% glvideo Mean tick time across 100 ticks: macosx1014-64-shippable-qr e10s stylo webgl-ipc webrender 33.06 -> 16.15
19% glvideo Mean tick time across 100 ticks: linux64-shippable e10s stylo 14.08 -> 11.38
18% glvideo Mean tick time across 100 ticks: linux64-shippable-qr e10s stylo webrender 13.94 -> 11.37
18% glvideo Mean tick time across 100 ticks: linux64-shippable-qr e10s stylo webrender-sw 13.90 -> 11.45

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=28484

:jgilbert can you please confirm that this is expected?

Flags: needinfo?(jgilbert)

I wasn't expecting the minor linux perf improvement, but otherwise Win/Mac are as expected. Love to see it working! :)

Flags: needinfo?(jgilbert)
Regressions: 1678989
Regressions: 1699558
Regressions: 1709726
You need to log in before you can comment on or make changes to this bug.