¡Hola!

Whenever somebody shares their screen on https://meet.google.com the presentation is clipped to just the top left corner.

Steps:

• Join a meeting with Firefox
• Have someone present their screen

Actual:
The shared screen is clipped to the top left corner.

Expected:
The shared screen is visible correctly.

Browser console contents:
WARNING! //scs/mss-static//js/k=boq-rtc.MeetingsUi.en.ax7z4yfUBR4.es5.O/am=ghAQGAAAgBMDAAgAREAKAwAAAAACgP9_:600:256
Using this console may allow attackers to impersonate you and steal your information using an attack called Self-XSS.
Do not enter or paste code that you do not understand. //scs/mss-static//js/k=boq-rtc.MeetingsUi.en.ax7z4yfUBR4.es5.O/am=ghAQGAAAgBMDAAgAREAKAwAAAAACgP9_:600:256
Some cookies are misusing the “sameSite“ attribute, so it won’t work as expected 388
Some cookies are misusing the “sameSite“ attribute, so it won’t work as expected 5
Attempt to set a forbidden header was denied: Connection 1670617852-lcs_client_bin.js:147:393
Attempt to set a forbidden header was denied: Connection 1670617852-lcs_client_bin.js:147:393
Attempt to set a forbidden header was denied: Connection 1670617852-lcs_client_bin.js:147:393
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified 3
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). 2 onloadwff.js:71:798525
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). 4 onloadwff.js:71:444527
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
Attempt to set a forbidden header was denied: Connection 1670617852-lcs_client_bin.js:147:393
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
Attempt to set a forbidden header was denied: Connection 1670617852-lcs_client_bin.js:147:393

Please let me know if there's anything I could capture when this issue manifest itself.

¡Gracias!
Alex

Hola Alex,

Thank you for your report. I've tried on Linux, OS X and Windows and it is not reproducing for me. Is this happening on Windows 10? Does it occur with other services (https://whereby.com/) and using our WebRTC landing tests (https://mozilla.github.io/webrtc-landing/gum_test.html)? There was an older Bug 1392565 that I closed because I was unable to reproduce. I wonder if this is the same issue, and you happen to have hardware where the problem shows up.

¡Gracias!
Dan

Hi Alex, sorry for the long delay in getting back to you. The fact that you're seeing something weird on gum_test.html makes it sound like we're hitting a problem with your hardware and not something to do with Meet, so I don't think a test call will help right now.

I just experienced this, too. The person sharing their screen was using Chrome but I couldn't tell what OS. I was using today's Nightly on an updated Windows 10 machine.

I'll needinfo dminor here so he sees this in case there's something I can do to help track this down.

Thanks! We also have Bug 1673563, which looks like something similar. We're going to follow up with Meet and see if they have any ideas as to what might be happening here.

I was on a call with overholt earlier today on whereby.com (both of us using Firefox Nightly) and we saw the same issue. We were able to reproduce it a couple times by
(1) me sharing a window
(2) stopping the share from Firefox (which whereby seemed unaware of - it would just show a freeze frame of the last thing that was up in the share)
(3) stopping the share in the whereby UI

After I did this, my video came back cropped for him (I did not appear cropped in my own view).

Thanks for the extra info!

That jogged an old memory, I hit this two or three times in my 1:1s with Nils a while ago, maybe summer 2019 or even earlier, where I would sometimes get cropped video from him that would go away after a tab refresh. So one possibility is a receive side problem in Firefox, likely one that has been around for a while, but some changes with Meet have caused it to occur a lot more frequently.

Switching from window share back to camera would change the send resolution, maybe we're not handling that properly sometimes. I wasn't able to get this to happen with the STR above, but we might be able to trigger this by artificially varying the send resolution in Firefox and watching what happens on the receive side. I'll have a quick look.

I spent some more time today sharing a window and constantly resizing the window to generate changes in the send resolution without triggering this bug. The next time this shows up, the contents of about:webrtc on the receive side will contain a history of the resolution changes which might be helpful in narrowing this down.

Windows seems to be a common thread in these reports, but my old Windows laptop was left pretty much unusable after an OS update, so I'm not able to test that configuration right now.

I'm experiencing a similar issue to this, but I'm not sure if it's directly related. Sometimes when I try to share something on my external monitor, the screencast will be only as big as the resolution of my internal monitor and therefore only shows about 1 / 4 of the actual screen.

(In reply to Jovan Gerodetti from comment #10)

I'm experiencing a similar issue to this, but I'm not sure if it's directly related. Sometimes when I try to share something on my external monitor, the screencast will be only as big as the resolution of my internal monitor and therefore only shows about 1 / 4 of the actual screen.

We are all using macOS 10.15.7 with Firefox Beta / Dev Edition. The issue appeared a couple of weeks ago.

Hi Jovan, problems with a multiple monitor setup is quite possibly a separate issue. Could you please file a new bug for that? Thank you!

Snipped from an about:webrtc where the problem reproduced:

Video Frame Statistics - MediaStreamTrack Id: {080baba5-b080-4580-b016-c9dce22e283c}
Width (px)	Height (px)	Consecutive Frames	Time Elapsed (s)	Estimated Framerate	Rotation (degrees)	First Frame Reception Timestamp	Last Frame Reception Timestamp	Local Receiving SSRC	Remote Sending SSRC
1280	720	14432	1382.309	10.44	0	1605629290660	1605630672969	2619317479	2619317479
320	180	4801	523.980	9.16	0	1605630679652	1605631203632	2619317479	2619317479

The receiver was Firefox 85, the sender Firefox 84.

So it looks like the sender decides to send lower resolution video, but rather than scaling the entire image, it is clipping to the top left corner.

So we have a call to I420Buffer::CropAndScaleFrom here [1], which we've been doing for a long time. Maybe we should just use ScaleFrom when we're screensharing?

[1] https://searchfox.org/mozilla-central/rev/277ab3925eae21b419167a34624ec0ab518d0c94/dom/media/webrtc/MediaEngineRemoteVideoSource.cpp#572

My kids just started hitting this bug with their school work, which is prompting their school district to issue the standard "Use Chrome" whenever they discover we're using Firefox. Since Meet is so prevelant in school systems, this might need to be a higher priority/severity.

Also, they've never hit it before upgrading to Fx83. When I get time, I'll see if I can I get more info.

I'm hitting this as well, what information about my system can I provide to assist with diagnosing the issue? I'm currently on 83.0 and Windows 10 Home 20H2.
Sorry, I'm brand new and signed up just because I was facing this issue.

Thank you to everyone who has provided information here! We've been in touch with Meet developers and they have provided us with steps to reproduce the issue, which will hopefully lead to a fix soon. Interestingly, they were not able to identify a regression range using Mozregression. That might indicate that this is a site change on Meet that has exposed a pre-existing bug in Firefox, or at least made it much more common.

I'm also experiencing this. I had to re-join everytime it happens. I have no choice, I didn't wanted to use another browser. Hopefully it gets fixed soon. When someone screenshares it just shows the top left corner.

Confirming: bug 1656252 is not the same as this despite the symptom being the same (I think)?

I think this is likely the same as Bug 1656252.

We've reached out to our contacts at Meet to confirm that switching the pref media.navigator.mediadatadecoder_vpx_enabled to false fixes things. If anyone cc'd on this bug would like to try the same, that would be very helpful. If the pref change doesn't fix things, then I guess we do in fact have two separate bugs.

I'll try to summarize what we know.

• Reports so far are on Windows.
• Comment 5 reports this even with Chrome as the sender, suggesting a receive-side bug.
• media.navigator.mediadatadecoder_vpx_enabled controls this, and allows hw decoding of vp8 and vp9 on Windows.
• Both Alex' and Andrew's about:support info indicates they have intel graphics cards that support hw decoding both VP8 and VP9.

This narrows down where to look. I have a windows machine with an nvidia card that supports vp9 decoding. I'll see if that is a common factor too.

I didn't even get to verifying which codec was used, but if I do a window share on whereby.com from nightly on linux to nightly on windows I get a corrupt video on the receiving end if I on the sending side shrink the captured window. Increasing the size of the captured window works as intended.

The corruption I see seems to occur on init of the wmf decoder with vp8 in hardware (Intel HD Graphics 630). Whether it's in the GPU process or the RDD process doesn't matter.

The way I've been triggering this is to have one browser instance doing screenshare on whereby.com (any service really, but preferably p2p to avoid any meddling middlemen). Another, the one that will be exhibiting the bug, joins the same room.
In the former instance, run something like this in the console:

v = document.getElementsByTagName("video")[1]
// Make sure this was the right element!
s = v.srcObject
t = s.getTracks()[0]
flipper = true
interval = setInterval(() => { t.applyConstraints({height: {max: flipper ? 1080 : 64}}); flipper = !flipper; }, 3000)

// And once you see the bug in the other instance:
clearInterval(interval)

VP9 is working fine in hw with both my intel and nvidia cards. If someone has an nvidia card with vp8 hw decoding, that would be an interesting data point.

It happend to me also, no matter if the meet windows was pinned or not, it happened also in Chrome, so I think is a bug from Meet.

The issue is actually in libwebrtc when a connection is being reset and a new one created.

When the video decoder is created webrtc::VideoDecoder::InitDecoder is called [1] with a webrtc::VideoCodec that contains the width and height of the video [2].

Then the data starts flowing via successive calls to webrtc::VideoDecoder::Decode [3].

The WebrtcMediaDataDecoder implements those methods (it inherits from webrtc::VideoDecoder). So when InitDecoder is called; we initialise the decoder for the required dimension, and in Decode we decode the video and send the images to the compositor.

In this particular case here, what we see is that from time to time webrtc::VideoDecoder::InitDecoder is called for a resolution of 320x180, but the first frame seen is actually 1538x1050.

When using ffmpeg's ffvp8 or libvpx; which dimensions we give when initialise the decoder isn't used. The bytestream itself dictactes what the resolution will end up being.

The hardware decoder however works differently, at the start it creates a DXVA decoder and a MFT Transform to copy the decoded data into a shareable surface.
So the decoder outputs a 1538x1050 image and copy it into a 320x180 one. And so we see that cropping.

We don't see the issue for the VP9 decoder by chance, because a VP9 decoder is only created when we see the first frame [4] (this was done to be compatible with the mac VP9 HW decoder available in bigsur and implemented in bug 1657521. So side effect is that we use the real resolution found in the VP9 bytestream to create the decoder, not the dummy one provided by libwebrtc.

So an easy work around would be to lazily initialise the VP8 decoder in the same fashion: wait for the first frame.

The best fix really would be to fix libwebrtc so it doesn't send rubbish dimensions. I leave this task to whomever wants it :)

[1] https://searchfox.org/mozilla-central/rev/1843375acbbca68127713e402be222350ac99301/third_party/libwebrtc/webrtc/api/video_codecs/video_decoder.h#63-64
[2] https://searchfox.org/mozilla-central/rev/1843375acbbca68127713e402be222350ac99301/third_party/libwebrtc/webrtc/common_types.h#564-565
[3] https://searchfox.org/mozilla-central/rev/1843375acbbca68127713e402be222350ac99301/third_party/libwebrtc/webrtc/api/video_codecs/video_decoder.h#66-70
[4] https://searchfox.org/mozilla-central/rev/1843375acbbca68127713e402be222350ac99301/dom/media/platforms/wrappers/MediaChangeMonitor.cpp#166-167

Get around a bug in libwebrtc where the video's size provided during the initialisation doesn't actually match the dimensions of the video actually provided.

For this we use the ability of the MediaChangeMonitor to lazily create decoder.
We need to tweak it however when in use with webrtc (where there's no concept of aspect ratio) so that the original dimensions are completely ignored.

The concept of ImageRect only exists with the WebM container. It defines a rectangle that will be used to crop the decoded image.

Initially (and as still indicated in the comment for VideoInfo.mImageRect) that field was only ever initialised by the WebMDemuxer.
So we now make this an optional value that needs to be explicitly initialised to be active, and only do so in the WebMDemuxer.

Many decoders are using the image size provided on initilization to determine how to create the decoded image. This can sometimes be incorrect like in WebRTC.

We now check if the image or display size is inconsistent with the bytestream data and if so force the creation of a new decoder to ensure it has valid initialization data.

This is what was already done for H264 as the initialization data was constructed from the SPS NAL (which is first required to instantiate a new decoder).

This is also a better fix for bug 1525230 which got around the bad aspect ratio. Following P1, there's no concept of aspect ratio left when the decoder is used outside of WebM container.

Depends on D99601

https://hg.mozilla.org/mozilla-central/rev/aa3a0821281a
https://hg.mozilla.org/mozilla-central/rev/6180177f388a

The patch landed in nightly and beta is affected.
:jya, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

The code is disabled by pref in beta and release.

This patch will allow the pref to be enabled again, but no need for uplifting

The regression testing bug 1656252 indicated this bug has existed since Firefox 78, but it doesn't affect Beta or Release since media.navigator.mediadatadecoder_vpx_enabled is false.

Actually the pref was enabled in Firefox 83 but then disabled after.

Checked with :cfogel on Win10 - 19041 / Win10 - 19041.804 / calls between them + macOS 11 but the issue did not reproduce for us.
Major builds checked were 83.0, 83.0a1(2020-05-13), 86.0, 88.0a1(2020-01-25) and several other Nightly ones, but the reported issue did not reproduce.
Before marking as verified would like to confirm with Alex that the issue is fixed for him as well.

¡Hola Oana!

I'd say this now works for me on Firefox Nightly 88 and maybe even prior versions.

Thanks for the ping and apologies for not getting back here on the bug being resolved ealier.

¡Gracias!
Alex