Closed Bug 1619543 Opened 4 months ago Closed 3 months ago

[Wayland][VA-API] libva symbol lookup errors

Categories

(Core :: Audio/Video: Playback, defect, P5)

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla77
Tracking Status
firefox-esr68 --- unaffected
firefox73 --- unaffected
firefox74 --- unaffected
firefox75 --- disabled
firefox76 --- disabled
firefox77 --- fixed

People

(Reporter: grayshade, Assigned: stransky)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #1619530 +++

[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

The messages might be misleading, but I don't know how to check otherwise. See https://bugzilla.mozilla.org/show_bug.cgi?id=1619530#c6 for about:support and https://bugzilla.mozilla.org/show_bug.cgi?id=1619530#c4 for LD_DEBUG output.

Can you attach output of firefox running with MOZ_LOG="PlatformDecoderModule:5" and with WAYLAND_DEBUG=1?
Thanks.

Flags: needinfo?(grayshade)
Attached file fx.txt (obsolete) —
Flags: needinfo?(grayshade)

From the log it looks like you have an old nightly version where va-api is not implemented. I don't see any mention about va-api init there.

It's the 20200302212732 build, do I need a newer one?

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

It's the 20200302212732 build, do I need a newer one?

Yes, that's correct. va-api is not even initialized, it may mean you're not playing h.264 clip as h.264 is only supported now.

Attached file fx2.txt

Ah, thanks. Added new log courtesy of h264ify. Is it working now?

[h264 @ 0x7fd0a4651800] Format vaapi_vld requires hwaccel initialisation.
[h264 @ 0x7fd0a4651800] Considering format 0x3231564e -> nv12.
[h264 @ 0x7fd0a4651800] Picked nv12 (0x3231564e) as best match for yuv420p.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0.
[AVHWFramesContext @ 0x7fd0afc2e100] Direct mapping possible.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x1.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x2.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x3.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x4.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x5.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x6.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x7.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x8.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x9.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0xa.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0xb.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0xc.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0xd.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0xe.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0xf.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x10.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x11.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x12.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x13.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x14.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x15.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x16.
[AVHWFramesContext @ 0x7fd0afc2e100] Created surface 0x17.
[h264 @ 0x7fd0a4651800] Considering format 0x3231564e -> nv12.
[h264 @ 0x7fd0a4651800] Picked nv12 (0x3231564e) as best match for yuv420p.
[h264 @ 0x7fd0a4651800] Decode context initialised: 0/0x10000000.
[h264 @ 0x7fd0a4651800] Reinit context to 640x368, pix_fmt: vaapi_vld
[h264 @ 0x7fd0a4651800] no picture 
[h264 @ 0x7fd0a4651800] Param buffer (type 0, 672 bytes) is 0.
[h264 @ 0x7fd0a4651800] Param buffer (type 1, 240 bytes) is 0x1.
[h264 @ 0x7fd0a4651800] Slice 0 param buffer (3128 bytes) is 0x2.
[h264 @ 0x7fd0a4651800] Slice 0 data buffer (22231 bytes) is 0x3.
[h264 @ 0x7fd0a4651800] Decode to surface 0x17.
[h264 @ 0x7fd0a4651800] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1
[h264 @ 0x7fd0a4651800] Param buffer (type 0, 672 bytes) is 0x3.
[h264 @ 0x7fd0a4651800] Param buffer (type 1, 240 bytes) is 0x2.
[h264 @ 0x7fd0a4651800] Slice 0 param buffer (3128 bytes) is 0x1.
[h264 @ 0x7fd0a4651800] Slice 0 data buffer (894 bytes) is 0.
[h264 @ 0x7fd0a4651800] Decode to surface 0x16.

Is H.264 whitelisted temporarily, or ar the other codecs hard to support. Most of YouTube seems to be VP9 and AV1 these days.

Attachment #9130381 - Attachment is obsolete: true
Priority: -- → P5

May want to make the log less verbose.

(In reply to Laurențiu Nicola from comment #6)
Yes, the log indicates that va-api is used.

Is H.264 whitelisted temporarily, or ar the other codecs hard to support. Most of YouTube seems to be VP9 and AV1 these days.

That's Bug 1619258

Assignee: nobody → stransky
Pushed by shindli@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8ba0167147a8
Don't log missing va-api symbols, r=jya
Status: UNCONFIRMED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

You need to log in before you can comment on or make changes to this bug.