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.

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.

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

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?

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.

(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.

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

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

Depends on D170625

Depends on D170626

Copying crash signatures from duplicate bugs.

https://hg.mozilla.org/mozilla-central/rev/ce20888662f7
https://hg.mozilla.org/mozilla-central/rev/31d23318230a
https://hg.mozilla.org/mozilla-central/rev/602247c99125
https://hg.mozilla.org/mozilla-central/rev/77034005a42a
https://hg.mozilla.org/mozilla-central/rev/cf328273030f

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.