Closed Bug 1641603 Opened 4 years ago Closed 3 years ago

[wayland] Using VA-API breaks GIF support in web.whatsapp

Categories

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

76 Branch
x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox76 --- disabled
firefox77 --- disabled
firefox78 --- disabled
firefox90 --- fixed

People

(Reporter: mweires, Assigned: emilio)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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

Steps to reproduce:

  • Enable widget.wayland-dmabuf-vaapi.enabled
  • Open web.whatsapp.com and choose a GIF by tenor. GIF service provided by web.whatsapp in the keyboard.

Actual results:

  • Searching for a term shows several GIFs which are playing as expected.
  • Choosing a GIF shows "1 file you were trying to add, is not supported".

Expected results:

  • Choosing a GIF prompts the user to send it. Sent afterwards.

The GIF feature of web.whatsapp is working as expected while widget.wayland-dmabuf-vaapi.enabled is disabled.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Component: Widget: Gtk → Audio/Video
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

This sounds like bug 1628690. Does it work with https://nightly.mozilla.org?

Thanks! I could reproduce this, it's not fixed. Disabling widget.wayland-dmabuf-vaapi.enabled fixes the problem.

Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Audio/Video → Audio/Video: Playback
Ever confirmed: true
Priority: -- → P5

From the media log it looks like the frames are decoded correctly, I don't see any error there.

VAAPI also breaks the drag and drop feature for video files in web.whatsapp. The same error message is shown when dragging mp4 files in the chat. The same file is working when disabling widget.wayland-dmabuf-vaapi.enabled.

I've reported the bug to Whatsapp on the 14th of July but did not receive a response yet.

@stransky: I see this as the last major issue which will keep most users from a bugfree experience when enabling VAAPI. Do you think this is purely a JS bug on Whatsapps side?

Flags: needinfo?(stransky)

No, this is a bug in Firefox.

Flags: needinfo?(stransky)

Thank you for the information. I'll close my ticket with the Whatsapp support.

VAAPI support has matured quite a bit with recent releases of FF. In my experience for the last 8 months this bug has been the last show stopper for enabling vaapi permanently - I've disabled/enabled it many times to send GIFs. Several duplicates of this bug confirm that this is also affecting video uploads to web.whatsapp.

How can we get this rolling? Let's get this fixed.

I wanted to revive this as - even if Whatsapp comes from Evil Corp - it's still an extremly wide used service. The VAAPI feature has broken the web.whatsapp support for video files and GIFs for 12 releases now. I'm not a Firefox dev, but if you can point me to the location where this goes wrong I'll look into it and send a PR.

Hi, the code is here:
https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg

How-to build Firefox on Linux:
https://dev.to/soumyalahiri/building-firefox-on-ubuntu-4bd8
(you may want to produce a debug build).

When you download and build the debug build, you can investigate the code at
https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg

You may need to run Firefox with e10s disabled which allows you to debug media code in the main (chrome) process.

Feel free to ask if you need any help.
Thanks.

Flags: needinfo?(emilio)

Here's a patch that "fixes" it:

diff --git a/dom/canvas/CanvasRenderingContext2D.cpp b/dom/canvas/CanvasRenderingContext2D.cpp
index 2f6c8cb0707d6..be906f748bc0b 100644
--- a/dom/canvas/CanvasRenderingContext2D.cpp
+++ b/dom/canvas/CanvasRenderingContext2D.cpp
@@ -4545,7 +4545,7 @@ void CanvasRenderingContext2D::DrawImage(const CanvasImageSource& aImage,
       //   - The image is bad, but it's not in the broken state (i.e., we could
       //     decode the headers and get the size).
       if (!res.mIsStillLoading && !res.mHasSize) {
-        aError.ThrowInvalidStateError("Passed-in image is \"broken\"");
+        // aError.ThrowInvalidStateError("Passed-in image is \"broken\"");
       }
       return;
     }

The issue is that WhatsApp is trying to call drawImage() on a canvas with the video as an argument (to create a thumbnail), and when VAAPI is in use we fail to get a surface and throw.

Assignee: nobody → emilio
Blocks: 1712588

We do have a size even if we can't turn the image into a SourceSurface,
and per spec in that case we shouldn't throw from
CanvasRenderingContext2D::DrawImage.

Note that per
https://html.spec.whatwg.org/#check-the-usability-of-the-image-argument
we should never ever throw for video anyways. Bug 1629381 covers that
(I'll try to reland with android tests fixed).

But this is correct and less invasive too.

Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5f5495a8dccc Fix order of checks in nsLayoutUtils::SurfaceFromElement(HTMLVideoElement*). r=nical
Flags: needinfo?(emilio)
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch

I can confirm the fix is working beautifully in Firefox 90. Have not found any regressions or other issues on web.whatsapp with enabled VAAPI so far.

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

Attachment

General

Created:
Updated:
Size: