Closed Bug 1809026 Opened 2 years ago Closed 2 years ago

Fix VA-API -> WebGL texture path

Categories

(Core :: Graphics, enhancement, P3)

Firefox 108
enhancement

Tracking

()

RESOLVED FIXED
112 Branch
Tracking Status
firefox112 --- fixed

People

(Reporter: elfarto, Assigned: stransky)

References

(Blocks 1 open bug)

Details

Crash Data

Attachments

(6 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0

Steps to reproduce:

Play https://www.youtube.com/watch?v=FWYzdJJVpIQ at 2160s60 quality on Linux with VA-API enabled and nvidia-vaapi-driver installed.

Actual results:

Video playback framerate is very low, approx. 15fps, rather than the 60fps of the source video. Selecting 720s60 results in a much smoother playback experience.

I took some profiles during playback:
2160s60 profile: https://share.firefox.dev/3vLANPd
720s60 profile: https://share.firefox.dev/3CwjDJa

They show a lot of time spent copying the frame around, which would explain why the larger resolution is much slower.

Expected results:

The video should play back smoothly.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
Severity: -- → S3

Can you run it on terminal with MOZ_LOG="PlatformDecoderModule:5 Dmabuf:5" env variables and attach the output here? Looks like we copy the dmabuf frames instead of share them via IPC bridge.
Thanks.

Flags: needinfo?(elfarto)
Attached file 1809026-vr-bug.log

Log of VR play back at 2160s with MOZ_LOG="PlatformDecoderModule:5 Dmabuf:5" set.

Flags: needinfo?(elfarto)

DMABufSurfaceRGBA::Create() doesn't look correct in the log. I wonder what calls it and why. Do you play it from YouTube or is that a plain video file?

Flags: needinfo?(elfarto)
Summary: Laggy playback of 4k VR Youtube video with VA-API/NVIDIA/Linux → DMABufSurfaceRGBA::Create() is called during VA-API playback

Also can you try latest nightly?

Yes, I understand now. It's really about https://www.youtube.com/watch?v=FWYzdJJVpIQ clip which uses video clip as texture for WebGL. So it's not about NVIDIA but how we transfer textures from VA-API to WebGL.

Flags: needinfo?(elfarto)
Summary: DMABufSurfaceRGBA::Create() is called during VA-API playback → Fix VA-API -> WebGL texture path
Component: Audio/Video: Playback → Graphics

(In reply to Martin Stránský [:stransky] (ni? me) from comment #6)

Yes, I understand now. It's really about https://www.youtube.com/watch?v=FWYzdJJVpIQ clip which uses video clip as texture for WebGL. So it's not about NVIDIA but how we transfer textures from VA-API to WebGL.

Correct. I've tried the video on the latest Firefox nightly, but that has the same issue.

Assignee: nobody → stransky
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Type: defect → enhancement

DMABufSurface is exported/referenced by Serialize and the reference is carried over IPC bridge (by SurfaceDescriptor) to a new DMABufSurface object.
When the new DMABufSurface object is deleted the reference is also handled.

But GPUVideoTextureData does not create DMABufSurface from SurfaceDescriptor so we need to unref it at RemoteDecoderManagerParent::RecvDeallocateSurfaceDescriptorGPUVideo().

Depends on D167240

Priority: -- → P3
Attachment #9313563 - Attachment is obsolete: true

Recently we add DMABufSurface reference when DMABufSurface is exported over IPC bridge by Serialize().
That no longer works as Serialize() may be called more times due to WebGL integration.

In this patch remove ref add in Serialize() (GlobalRefCountExport) and add global ref when it's
created/imported by IPC bridge.

That better matches DMABufSurface cycle in compositor as DMABufSurface is referenced on create and undef when it's deleted on compositor side.

Also add logging to ref/unref and print warning if surface ref count is already zero (we're trying to unref already 'unused' surface).

Right now we add global reference to DMABufSurface in VideoFrameSurface when it's allocated by decoder and release it when DMABUFSurfaceImage deleted by MediaSupervisor.
It's not veri obvious so in this patch we move DMABufSurface references to DMABUFSurfaceImage only, we add globak ref when DMABufSurface is put to DMABUFSurfaceImage
and unref when DMABUFSurfaceImage is deleted.

Depends on D170624

Duplicate of this bug: 1817812

Copying crash signatures from duplicate bugs.

Crash Signature: [@ mozilla::layers::DMABUFSurfaceImage::DMABUFSurfaceImage]
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/ce20888662f7 [Linux] Implement fast DMABuf WebGL textures upload r=jgilbert
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/31d23318230a [Linux] Reference DMABufSurface when it's created/imported r=emilio https://hg.mozilla.org/integration/autoland/rev/602247c99125 [Linux] Move global DMABufSurface management from VideoFrameSurface to DMABUFSurfaceImage r=alwu https://hg.mozilla.org/integration/autoland/rev/77034005a42a [Linux] Check and log FFMPEG HW surfaces ID so we're sure we don't use the same surface twice r=alwu https://hg.mozilla.org/integration/autoland/rev/cf328273030f [Linux] Set Debug log ffmpeg level for VA-API decoding r=alwu
Regressions: 1829542

Seems like the Vimeo VR player triggers the same memcpy issue, for instance this video: https://vimeo.com/channels/360vr/277503248

(In reply to Stephen from comment #19)

Seems like the Vimeo VR player triggers the same memcpy issue, for instance this video: https://vimeo.com/channels/360vr/277503248

Yes, it's the same. But do you still see the bug with latest Nightly?

Yes, it's the same. But do you still see the bug with latest Nightly?

Yes, same bug, with build: 20230620094433.

(In reply to Stephen from comment #21)

Yes, it's the same. But do you still see the bug with latest Nightly?

Yes, same bug, with build: 20230620094433.

Please file a new bug for it.
Thanks.

btw. Looks like https://phabricator.services.mozilla.com/D167240 is broken somehow so we don't use fast path for dmabuf surfaces.

Flags: needinfo?(stransky)
See Also: → 1839809
Flags: needinfo?(stransky)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: