Firefox fails to load vaapi related ffmpeg library symbols on certain configurations in the latest firefox nightly with bug id: 1616185 resolved.

The library symbols which fails to load are as follows:

[Child 2607: Main Thread]: D/PlatformDecoderModule Couldn't load function avcodec_get_hw_config
[Child 2607: Main Thread]: D/PlatformDecoderModule Couldn't load function av_hwdevice_ctx_create
[Child 2607: Main Thread]: D/PlatformDecoderModule Couldn't load function av_hwframe_transfer_get_formats
[Child 2607: Main Thread]: D/PlatformDecoderModule Couldn't load function av_hwdevice_ctx_create_derived

However running readelf -Ws /usr/lib64/libavcodec.so | grep av_hwdevice_ctx_create gives
509: 0000000000000000 0 FUNC GLOBAL DEFAULT UND av_hwdevice_ctx_create@LIBAVUTIL_56 (8)

Running with LD_DEBUG=libs ./firefox I noticed:

calling init: /home/akarshan/Public/firefox/libmozavcodec.so
      3222:	
      3222:	/home/akarshan/Public/firefox/libmozavcodec.so: error: symbol lookup error: undefined symbol: avcodec_get_hw_config (fatal)
      3222:	/home/akarshan/Public/firefox/libmozavcodec.so: error: symbol lookup error: undefined symbol: av_hwdevice_ctx_create (fatal)
      3222:	/home/akarshan/Public/firefox/libmozavcodec.so: error: symbol lookup error: undefined symbol: av_hwframe_transfer_get_formats (fatal)
      3222:	/home/akarshan/Public/firefox/libmozavcodec.so: error: symbol lookup error: undefined symbol: av_hwdevice_ctx_create_derived (fatal)
      3222:	find library=libva.so.2 [0]; searching
      3222:	 search path=/home/akarshan/Public/firefox		(LD_LIBRARY_PATH)
      3222:	  trying file=/home/akarshan/Public/firefox/libva.so.2
      3222:	 search cache=/etc/ld.so.cache
      3222:	  trying file=/usr/lib/libva.so.2

The following log(s) are attached as requested:

1. MOZ_ENABLE_WAYLAND=1 MOZ_LOG="WidgetWayland:5" ./firefox

Please attach about:support page. From the log it looks like HW acceleration is disabled.

Sharing pastbin link since I can't find how to attach.

Please see: link

"windowProtocol": "wayland" should be "windowProtocol": "wayland/drm". It means dmabuf is disabled on your system. Which distro/compositor do you run?

(In reply to Martin Stránský [:stransky] from comment #3)

"windowProtocol": "wayland" should be "windowProtocol": "wayland/drm". It means dmabuf is disabled on your system. Which distro/compositor do you run?

Gnome Desktop 3.34

I guessed it right. Mutter compositor doesn't support zwp_linux_dmabuf protocol on amdgpu, however, wl_drm is supported!
My AMDGPU doesn't support EGL_EXT_image_dma_buf_import_modifiers EGL extension which mutter needs to enable the mentioned protocol.

Sigh, sorry. As I was saying, I'm not sure if it's an issue or not -- the library does get loaded in the content process and the functions are there (I checked with gdb).

Unfortunately, I'm not convinced it's working -- I don't see any improvement in CPU usage.

Distro is Arch linux .

However from the fact that others are facing, this seems to be different issue.

(In reply to Laurențiu Nicola from comment #7)

Sigh, sorry. As I was saying, I'm not sure if it's an issue or not -- the library does get loaded in the content process and the functions are there (I checked with gdb).

Unfortunately, I'm not convinced it's working -- I don't see any improvement in CPU usage.

Please file a new bug for it. This one is about missing GPU acceleration.

(In reply to Akarshan Biswas from comment #5)

(In reply to Martin Stránský [:stransky] from comment #3)

"windowProtocol": "wayland" should be "windowProtocol": "wayland/drm". It means dmabuf is disabled on your system. Which distro/compositor do you run?

Gnome Desktop 3.34

I guessed it right. Mutter compositor doesn't support zwp_linux_dmabuf protocol on amdgpu, however, wl_drm is supported!
My AMDGPU doesn't support EGL_EXT_image_dma_buf_import_modifiers EGL extension which mutter needs to enable the mentioned protocol.

Akarshan, you're right. zwp_linux_dmabuf is needed for proper dmabuf GPU memory sharing. Which AMD card do you have?

This one is about missing GPU acceleration.

That's the thing, I get those "symbol lookup error" messages, but the symbols are there. So I'm not sure whether it's working or not. I'll file an issue about high CPU usage once this is resolved.

(In reply to Martin Stránský [:stransky] from comment #11)

(In reply to Akarshan Biswas from comment #5)

(In reply to Martin Stránský [:stransky] from comment #3)

"windowProtocol": "wayland" should be "windowProtocol": "wayland/drm". It means dmabuf is disabled on your system. Which distro/compositor do you run?

Gnome Desktop 3.34

I guessed it right. Mutter compositor doesn't support zwp_linux_dmabuf protocol on amdgpu, however, wl_drm is supported!
My AMDGPU doesn't support EGL_EXT_image_dma_buf_import_modifiers EGL extension which mutter needs to enable the mentioned protocol.

Akarshan, you're right. zwp_linux_dmabuf is needed for proper dmabuf GPU memory sharing. Which AMD card do you have?

AMD Radeon Rx 550 series, also tested it on my laptop which runs amd a10 apu. I think you need to implement dmabuf using wl_drm to support these cards.

(In reply to Akarshan Biswas from comment #13)

AMD Radeon Rx 550 series, also tested it on my laptop which runs amd a10 apu. I think you need to implement dmabuf using wl_drm to support these cards.

Well, no :) You're wrong. wl_drm is about rendering to screen and has nothing to do with dmabuf/video playback and so on. What you need is to update your graphics drivers/wayland stack to properly support wayland on your box. Perhaps your Wayland environment is too old.

(In reply to Martin Stránský [:stransky] from comment #14)

(In reply to Akarshan Biswas from comment #13)

AMD Radeon Rx 550 series, also tested it on my laptop which runs amd a10 apu. I think you need to implement dmabuf using wl_drm to support these cards.

Well, no :) You're wrong. wl_drm is about rendering to screen and has nothing to do with dmabuf/video playback and so on. What you need is to update your graphics drivers/wayland stack to properly support wayland on your box. Perhaps your Wayland environment is too old.

I run gnome 3.34 on latest arch linux in case you missed.

(In reply to Akarshan Biswas from comment #15)

I run gnome 3.34 on latest arch linux in case you missed.

In that case you should report it at arch linux bugzilla. I have almost identical amd card on Fedora 31 and zwp_linux_dmabuf is supported there. This can't be fixed on Firefox side.

(In reply to Martin Stránský [:stransky] from comment #16)

(In reply to Akarshan Biswas from comment #15)

I run gnome 3.34 on latest arch linux in case you missed.

In that case you should report it at arch linux bugzilla. I have almost identical amd card on Fedora 31 and zwp_linux_dmabuf is supported there. This can't be fixed on Firefox side.

Okay, but your should see this first. Thank you. :)

Okay, thanks, I'll look at it. Didn't know that wl_drm can be used this way.

looking again at about:support EGL_EXT_image_dma_buf_import is supported so perhaps the wl_drm can be used. I wonder why zwp_linux_dmabuf is missing.

Please run firefox with WAYLAND_DEBUG=1 and attach the log here.
Thanks.

zwp_linux_dmabuf is implemented by MESA - https://gitlab.freedesktop.org/wayland/wayland/issues/59 - which is open source GL implementation. Or do you use closed source AMD drivers?

(In reply to Martin Stránský [:stransky] from comment #22)

zwp_linux_dmabuf is implemented by MESA - https://gitlab.freedesktop.org/wayland/wayland/issues/59 - which is open source GL implementation. Or do you use closed source AMD drivers?

I use open source mesa drivers. AMDGPU does not require closed source drivers sir! :)

Please see here , they say it needs EGL_EXT_image_dma_buf_import_modifiers extension.

However this extension is optional. What really needed is, EGL_EXT_image_dma_buf_import.

Well, yes, I just wonder why do you miss the zwp_linux_dmabuf as you have almost identical setup as I with recent Wayland compositor etc. And I don't think it's related to AMD as I have zwp_linux_dmabuf available on my RX 570/Fedora.

(In reply to Martin Stránský [:stransky] from comment #24)

Well, yes, I just wonder why do you miss the zwp_linux_dmabuf as you have almost identical setup as I with recent Wayland compositor etc. And I don't think it's related to AMD as I have zwp_linux_dmabuf available on my RX 570/Fedora.

I just boot up Fedora and it's the same. Only my intel laptop has it.

eglinfo:

EGL client extensions string:
    EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query
    EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses
    EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_wayland
    EGL_EXT_platform_x11 EGL_MESA_platform_gbm
    EGL_MESA_platform_surfaceless EGL_EXT_platform_device

GBM platform:
amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
amdgpu: amdgpu_device_initialize failed.
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES 
EGL extensions string:
    EGL_ANDROID_blob_cache EGL_EXT_buffer_age
    EGL_EXT_image_dma_buf_import EGL_KHR_cl_event2 EGL_KHR_config_attribs
    EGL_KHR_create_context EGL_KHR_create_context_no_error
    EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses
    EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image
    EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image
    EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base
    EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync
    EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float
    EGL_KHR_wait_sync EGL_MESA_configless_context
    EGL_MESA_image_dma_buf_export EGL_MESA_query_driver

Wayland platform:
EGL API version: 1.5
EGL vendor string: Mesa Project
EGL version string: 1.5
EGL client APIs: OpenGL OpenGL_ES 
EGL extensions string:
    EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync
    EGL_EXT_buffer_age EGL_EXT_create_context_robustness
    EGL_EXT_image_dma_buf_import EGL_EXT_swap_buffers_with_damage
    EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context
    EGL_KHR_create_context_no_error EGL_KHR_fence_sync
    EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace
    EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image
    EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image
    EGL_KHR_image_base EGL_KHR_no_config_context EGL_KHR_reusable_sync
    EGL_KHR_surfaceless_context EGL_KHR_swap_buffers_with_damage
    EGL_EXT_pixel_format_float EGL_KHR_wait_sync
    EGL_MESA_configless_context EGL_MESA_drm_image
    EGL_MESA_image_dma_buf_export EGL_MESA_query_driver
    EGL_WL_bind_wayland_display EGL_WL_create_wayland_buffer_from_image

Okay I'll check that on my AMD card.

(In reply to Martin Stránský [:stransky] from comment #26)

Okay I'll check that on my AMD card.

Please note that zwp_dmabuf_linux isn't supported on radeon R5 mobile graphics as well.

MrCooper (Michel D.) in #radeon@irc.freenode.net replied:

IIRC https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2147 (plus possibly corresponding Wayland compositor changes) should address that
IIUC
it's because amdgpu doesn't support DRM modifiers yet

Okay, it may be possible to use it without modifiers.

Why is VAAPI turned on whenever someone enabled wayland?

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

@Jean, it's not enabled by default, it's behind the pref: widget.wayland-dmabuf-vaapi.enabled, which is false by default

@Martin I think this bug should block wayland-dmabuf and not vaapi.

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

Why is VAAPI turned on whenever someone enabled wayland?

Yes, it's disabled by default as well as HW acceleration on Wayland is disabled by default.

That's the thing, I get those "symbol lookup error" messages, but the symbols are there. So I'm not sure whether it's working or not. I'll file an issue about high CPU usage once this is resolved.

I had those symbols lookup errors when testing this before (https://bugzilla.mozilla.org/show_bug.cgi?id=1616128#c2). I still see those errors now and have no idea what's causing it (the symbols are there, I can see them with readelf too) but can safely say it doesn't break anything (at least for me) because VAAPI is working fine for me now.

My graphics card is a 5700XT and I'm using sway-git (476773dd32e2f423f58dea39fac8b2dc0ba085b9) built against wlroots-git (c9859f187f91c664da458e803d186ebef219618e), mesa-git (a933934efbf343b6df3ea65ac70545bf200986ef) built against llvm 11 (9284abd0040afecfd619dbcf1b244a8b533291c9).

zwp_linux_dmabuf is available:

$ weston-info | grep dmabuf
interface: 'zwp_linux_dmabuf_v1', version: 3, name: 2

I disabled media.av1.enabled and media.av1.use-dav1d for testing purposes because youtube likes to sometimes serve av1 video and have the h264ify add-on installed to force h264 video. I also had to whitelist syscall 312 (which belongs to http://man7.org/linux/man-pages/man2/get_robust_list.2.html according to https://syscalls.kernelgrok.com/) because I ran into a sandbox violation as follows:

Sandbox: seccomp sandbox violation: pid 13760, tid 13962, syscall 312, args 13760 13760 0 43 58 140508034916676. Killing process.

https://crash-stats.mozilla.org/report/index/9c412479-5f74-40e3-82bb-f97d20200304.

Running firefox with env MOZ_ENABLE_WAYLAND=1 firefox --MOZ_LOG=PlatformDecoderModule:4 confirms that vaapi is working:

[Child 21949: Main Thread]: D/PlatformDecoderModule Couldn't load function avcodec_get_hw_config
[Child 21949: Main Thread]: D/PlatformDecoderModule Couldn't load function av_hwdevice_ctx_create
[Child 21949: Main Thread]: D/PlatformDecoderModule Couldn't load function av_hwframe_transfer_get_formats
[Child 21949: Main Thread]: D/PlatformDecoderModule Couldn't load function av_hwdevice_ctx_create_derived
[Child 21949: Main Thread]: D/PlatformDecoderModule Sandbox decoder rejects requested type
<message repeated multiple times>
[Child 21949: Main Thread]: D/PlatformDecoderModule Sandbox decoder rejects requested type
[Child 21949: MediaPlayback #2]: D/PlatformDecoderModule Sandbox decoder rejects requested type
[Child 21949: MediaPlayback #2]: D/PlatformDecoderModule Sandbox decoder rejects requested type
[Child 21949: MediaPlayback #1]: D/PlatformDecoderModule Sandbox decoder rejects requested type
[Child 21949: MediaPlayback #1]: D/PlatformDecoderModule Sandbox decoder rejects requested type
[Child 21949: MediaPDecoder #1]: D/PlatformDecoderModule Initialising FFmpeg decoder.
[Child 21949: MediaPDecoder #2]: D/PlatformDecoderModule Initialising VA-API FFmpeg decoder
[AVHWDeviceContext @ 0x7fb71af07540] Trying to use DRM render node for device 0.
[AVHWDeviceContext @ 0x7fb71af07540] libva: VA-API version 1.7.0
[AVHWDeviceContext @ 0x7fb71af07540] libva: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so
[Child 21949: MediaPDecoder #1]: D/PlatformDecoderModule FFmpeg init successful.
[Child 21949: MediaPDecoder #1]: D/PlatformDecoderModule AudioTrimmer[0x7fb71cb8c160] ::operator(): sample[0,23219] no trimming information
[Child 21949: MediaPDecoder #1]: D/PlatformDecoderModule AudioTrimmer[0x7fb71cb8c160] ::HandleDecodedResult: sample[0,23219] (decoded[0,23219] no trimming needed
[AVHWDeviceContext @ 0x7fb71af07540] libva: Found init function __vaDriverInit_1_7
[AVHWDeviceContext @ 0x7fb71af07540] libva: va_openDriver() returns 0
[AVHWDeviceContext @ 0x7fb71af07540] Initialised VAAPI connection: version 1.7
[AVHWDeviceContext @ 0x7fb71af07540] Format 0x3231564e -> nv12.
[AVHWDeviceContext @ 0x7fb71af07540] Format 0x30313050 -> p010le.
[AVHWDeviceContext @ 0x7fb71af07540] Format 0x36313050 -> unknown.
[AVHWDeviceContext @ 0x7fb71af07540] Format 0x30323449 -> yuv420p.
[AVHWDeviceContext @ 0x7fb71af07540] Format 0x32315659 -> yuv420p.
[AVHWDeviceContext @ 0x7fb71af07540] Format 0x56595559 -> unknown.
[AVHWDeviceContext @ 0x7fb71af07540] Format 0x32595559 -> yuyv422.
[AVHWDeviceContext @ 0x7fb71af07540] Format 0x59565955 -> uyvy422.
[AVHWDeviceContext @ 0x7fb71af07540] Format 0x41524742 -> bgra.
[AVHWDeviceContext @ 0x7fb71af07540] Format 0x41424752 -> rgba.
[AVHWDeviceContext @ 0x7fb71af07540] Format 0x58524742 -> bgr0.
[AVHWDeviceContext @ 0x7fb71af07540] Format 0x58424752 -> rgb0.
[AVHWDeviceContext @ 0x7fb71af07540] VAAPI driver: Mesa Gallium driver 20.1.0-devel for AMD NAVI10 (DRM 3.36.0, 5.5.7-gentoo, LLVM 11.0.0).
[AVHWDeviceContext @ 0x7fb71af07540] Driver not found in known nonstandard list, using standard behaviour.
[h264 @ 0x7fb74db21800] nal_unit_type: 7(SPS), nal_ref_idc: 3
[h264 @ 0x7fb74db21800] nal_unit_type: 8(PPS), nal_ref_idc: 3
[Child 21949: MediaPDecoder #2]: D/PlatformDecoderModule VA-API FFmpeg init successful
[h264 @ 0x7fb74db21800] nal_unit_type: 5(IDR), nal_ref_idc: 1
[Child 21949: MediaPDecoder #1]: D/PlatformDecoderModule Choosing FFmpeg pixel format for VA-API video decoding.
[Child 21949: MediaPDecoder #1]: D/PlatformDecoderModule Requesting pixel format VAAPI_VLD
[h264 @ 0x7fb74db21800] Format vaapi_vld chosen by get_format().
[h264 @ 0x7fb74db21800] Format vaapi_vld requires hwaccel initialisation.
[h264 @ 0x7fb74db21800] Considering format 0x3231564e -> nv12.
[h264 @ 0x7fb74db21800] Picked nv12 (0x3231564e) as best match for yuv420p.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x1.
[AVHWFramesContext @ 0x7fb706c89a80] Direct mapping disabled: deriving image does not work: 1 (operation failed).
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x2.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x3.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x4.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x5.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x6.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x7.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x8.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x9.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0xa.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0xb.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0xc.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0xd.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0xe.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0xf.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x10.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x11.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x12.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x13.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x14.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x15.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x16.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x17.
[AVHWFramesContext @ 0x7fb706c89a80] Created surface 0x18.
[h264 @ 0x7fb74db21800] Considering format 0x3231564e -> nv12.
[h264 @ 0x7fb74db21800] Picked nv12 (0x3231564e) as best match for yuv420p.
[h264 @ 0x7fb74db21800] Decode context initialised: 0x19/0x1a.
[h264 @ 0x7fb74db21800] Reinit context to 1280x720, pix_fmt: vaapi_vld
[h264 @ 0x7fb74db21800] no picture 
[h264 @ 0x7fb74db21800] Param buffer (type 0, 672 bytes) is 0x1b.
[h264 @ 0x7fb74db21800] Param buffer (type 1, 240 bytes) is 0x1c.
[h264 @ 0x7fb74db21800] Slice 0 param buffer (3128 bytes) is 0x1d.
[h264 @ 0x7fb74db21800] Slice 0 data buffer (488 bytes) is 0x1e.
[h264 @ 0x7fb74db21800] Decode to surface 0x18.
[h264 @ 0x7fb74db21800] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1
[h264 @ 0x7fb74db21800] Param buffer (type 0, 672 bytes) is 0x1b.
[h264 @ 0x7fb74db21800] Param buffer (type 1, 240 bytes) is 0x1c.
[h264 @ 0x7fb74db21800] Slice 0 param buffer (3128 bytes) is 0x1d.
[h264 @ 0x7fb74db21800] Slice 0 data buffer (35 bytes) is 0x1e.
[h264 @ 0x7fb74db21800] Decode to surface 0x17.
[Child 21949: MediaPDecoder #2]: D/PlatformDecoderModule Got one VAAPI frame output with pts=0 dts=0 duration=16683 opaque=-9223372036854775808
[Child 21949: MediaPDecoder #2]: D/PlatformDecoderModule AudioTrimmer[0x7fb71cb8c160] ::operator(): sample[23219,46439] no trimming information
[h264 @ 0x7fb74db21800] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 0
[Child 21949: MediaPDecoder #2]: D/PlatformDecoderModule AudioTrimmer[0x7fb71cb8c160] ::HandleDecodedResult: sample[23219,46439] (decoded[23219,46438] no trimming needed
[Child 21949: MediaPDecoder #2]: D/PlatformDecoderModule AudioTrimmer[0x7fb71cb8c160] ::operator(): sample[46439,69659] no trimming information
[Child 21949: MediaPDecoder #2]: D/PlatformDecoderModule AudioTrimmer[0x7fb71cb8c160] ::HandleDecodedResult: sample[46439,69659] (decoded[46439,69658] no trimming needed
[h264 @ 0x7fb74db21800] Param buffer (type 0, 672 bytes) is 0x1b.
[h264 @ 0x7fb74db21800] Param buffer (type 1, 240 bytes) is 0x1c.
[h264 @ 0x7fb74db21800] Slice 0 param buffer (3128 bytes) is 0x1d.
[h264 @ 0x7fb74db21800] Slice 0 data buffer (33 bytes) is 0x1e.
[h264 @ 0x7fb74db21800] Decode to surface 0x16.
[Child 21949: MediaPDecoder #2]: D/PlatformDecoderModule AudioTrimmer[0x7fb71cb8c160] ::operator(): sample[69659,92879] no trimming information
[Child 21949: MediaPDecoder #2]: D/PlatformDecoderModule AudioTrimmer[0x7fb71cb8c160] ::HandleDecodedResult: sample[69659,92879] (decoded[69659,92878] no trimming needed
[Child 21949: MediaPDecoder #2]: D/PlatformDecoderModule AudioTrimmer[0x7fb71cb8c160] ::operator(): sample[92879,116099] no trimming information
[Child 21949: MediaPDecoder #2]: D/PlatformDecoderModule AudioTrimmer[0x7fb71cb8c160] ::HandleDecodedResult: sample[92879,116099] (decoded[92879,116098] no trimming needed
[Child 21949: MediaPDecoder #1]: D/PlatformDecoderModule Got one VAAPI frame output with pts=16683 dts=16683 duration=16683 opaque=-9223372036854775808

(In reply to Aidan Harris from comment #35)

I had those symbols lookup errors when testing this before (https://bugzilla.mozilla.org/show_bug.cgi?id=1616128#c2). I still see those errors now and have no idea what's causing it (the symbols are there, I can see them with readelf too) but can safely say it doesn't break anything (at least for me) because VAAPI is working fine for me now.

I filed bug 1619543 for this (VAAPI works fine, symbol errors in the logs).

Update: I tested latest Firefox Nightly on sway wm, zwp_linux_dmabuf works, including vaapi. I will try to open a mutter(the gnome compositor) bug report. I will try to explain them everything and I hope they will take it into consideration since other wayland compositors supports it.

If not, we have no choice but have to take it inside firefox itself.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a2e40c998ac45707ed4bffab76938e2962bd3a2c

https://hg.mozilla.org/mozilla-central/rev/331bbd402b0e

Can you test if latest nightly work for you? (You may need to disable sandbox, see Bug 1619585).
Thanks.

it works now in kwin wayland with rx 570

My EGL extension is missing modifiers and before this patch the "Window Protocol" was "wayland" on Ubuntu 19.10. Latest Nightly now shows "wayland/drm" and dmabuf appears to work with much better webGL performance (widget.wayland_dmabuf_webgl.enabled), particularly on https://bruno-simon.com.

(In reply to Martin Stránský [:stransky] from comment #42)

Can you test if latest nightly work for you? (You may need to disable sandbox, see Bug 1619585).
Thanks.

Yes. It works with sandbox security set to 0. I can see wl_drm is being used in the log. However if I enable the wayland webgl dmabuf setting, it hangs when put to full screen which I am trying to find out why.

@Martin. The issue with the fullscreen is fixed in the latest nightly 76. Is it possible to backport those fixes to 75 beta?

Thank you so much for you work!

(In reply to Akarshan Biswas from comment #46)

@Martin. The issue with the fullscreen is fixed in the latest nightly 76. Is it possible to backport those fixes to 75 beta?

Thank you so much for you work!

Please needinfo me in the actual bug. I'm not sure which one do you mean.
Thanks.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

(In reply to Martin Stránský [:stransky] from comment #47)

(In reply to Akarshan Biswas from comment #46)

@Martin. The issue with the fullscreen is fixed in the latest nightly 76. Is it possible to backport those fixes to 75 beta?

Thank you so much for you work!

Please needinfo me in the actual bug. I'm not sure which one do you mean.
Thanks.

Okay I checked and can confirmed that the Bug 1615098 as been marked for back porting to 75 beta.
Thanks again.