1215531 - Capturing some windows in WebRTC doesn't work properly on an Intel HD 2500 machine

Status: RESOLVED WORKSFORME

(Core :: WebRTC: Audio/Video, defect, P2)

Description

[Camelia Badau [:cbadau], Desktop Test Engineering]

Reproducible on Firefox 42 Beta 7 (buildID: 20151015151621)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0

Steps to reproduce: 
1. On one machine (machine A) open Firefox with a fresh profile.
2. Click Hello icon
3. Click 'Get Started'
4. Click 'Start a Conversation
5. Copy the conversation link and open it on another machine (machine B) and join the conversation.
6. On machine A, Click 'Share your screen' button. 
7. Select 'Share other Windows'. From the list, select to share Chrome window. 

Expected results: The window selected to share from the machine A is displayed on the machine B.

Actual results: There is a black screen shared on the machine B. The selected Chrome window to share from machine A isn't displayed on the machine B. 

NOTES:  
1. The issue is reproducible only on an Intel HD 2500 machine. Here are the graphics details: 

Adapter Description	Intel(R) HD Graphics
Adapter Drivers	igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32
Adapter RAM	Unknown
Asynchronous Pan/Zoom	none
Device ID	0x0152
Direct2D Enabled	true
DirectWrite Enabled	true (6.2.9200.17461)
Driver Date	8-21-2012
Driver Version	9.17.10.2843
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 11 (OMTC)
Subsys ID	00000000
Supports Hardware H264 Decoding	true
Vendor ID	0x8086
WebGL Renderer	Google Inc. -- ANGLE (Intel(R) HD Graphics Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote	true
AzureCanvasBackend	direct2d 1.1
AzureContentBackend	direct2d 1.1
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

2. The issue IS NOT reproducible on an Intel HD 4400 machine.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Please try capturing the window using https://mozilla.github.io/webrtc-landing/gum_test.html
You may need to add mozilla.github.io to the whitelist, or use aurora or nightly (which include it by default).

Also, please try capturing non-Chrome windows (calculator, Firefox, other apps), since it's possible the issue is with how the window is drawn into.

To verify: what OS is this?  Win7?

Likely this is some form of gfx driver issue/limitation/bug.

Comment 2

[Camelia Badau [:cbadau], Desktop Test Engineering]

Yes, it is Windows 7 64bit. 

I've tested with https://mozilla.github.io/webrtc-landing/gum_test.html and I have the following results: 
- capturing a Chrome window or an OpenOffice Writer document (odt) results in a black screen - like as in description
- capturing a Paint window, a pdf document, a Skype window or a Firefox window results in a page correctly displayed - no issue occurs here. 

Interesting is the fact that it works for several non-chrome windows/documents, while not for others, as mentioned above.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Very, very likely this is a driver issue having to do with how they're writing to the window.

The actual window capture code is here:
https://dxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/webrtc/modules/desktop_capture/window_capturer_win.cc#167

In addition to direct driver issues, if we believe the windows is invisible, or iconified, we'll return no frames or a 1x1 black frame.  I don't think that's what's happening here.

The other oddity in Windows 7 is how Aero is dealt with - is Aero on?  (the default is on)  Does resizing affect it?

Jimm, Aaron - any ideas?

Comment 4

[Jim Mathies [:jimm]]

I would start by stepping through our code looking for failures when sharing a google chrome window. If our code succeeds but we get black bits, I'd suggest we file a chromium bug on it.

Is there an easy way to test this that doesn't involve two computers?

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Jim Mathies [:jimm] from comment #4)
> I would start by stepping through our code looking for failures when sharing
> a google chrome window. If our code succeeds but we get black bits, I'd
> suggest we file a chromium bug on it.

I don't have the machine in question... (QA in romania I think)
 
> Is there an easy way to test this that doesn't involve two computers?

This shows up in gUM tests (https://mozilla.github.com/webrtc-landing/gum_test.html) -- a simple capture and display it tests.

Comment 6

[(No longer employed by Mozilla) Aaron Klotz]

No ideas, sorry :-(

Comment 7

[Camelia Badau [:cbadau], Desktop Test Engineering]

I've tested on Windows 7 64bit using Firefox 42 Beta 8 (buildID: 20151019161651): 
- with Aero on - the issue is not reproducible: capturing a Chrome window results in a page correctly displayed
- with Aero off (windows 7 basic theme) - the issue is reproducible: capturing a Chrome window results in a black screen - like as in description

Resizing doesn't affect it.

Comment 8

[Maire Reavy [:mreavy]]

@cbadau -- Can you retest and make sure the installed driver is reasonably current (i.e. latest release or close to)?   Thanks.

Comment 9

[Maire Reavy [:mreavy]]

@Dees -- To put a finer point on my last comment:  This is almost certainly a driver issue (and the driver being tested here was quite old). I'm asking the reporter to retest because I think we may be able to close this.

Comment 10

[Camelia Badau [:cbadau], Desktop Test Engineering]

I can't retest using Hello (as in Description) because Hello was removed (support for Hello was discontinued or "Could Not Connect To The Server" error is displayed in Firefox 42). 
But I've retested the initial issue using the https://talky.io page where I have also a Share Window option: the issue is not longer reproducible on the same machine with Intel HD Graphics 2500, but with the updated driver version (10.18.10.4226). I've tested on Windows 7 x64 using Firefox 42 RC and Firefox 50 RC.

Comment 11

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

(In reply to Maire Reavy [:mreavy] from comment #9)
> @Dees -- To put a finer point on my last comment:  This is almost certainly
> a driver issue (and the driver being tested here was quite old). I'm asking
> the reporter to retest because I think we may be able to close this.

Thanks, :maire. We'll await results on newer driver testing.

Comment 12

[Maire Reavy [:mreavy]]

Thanks, Camelia, for re-testing.  Talky.io is a good substitute.  Closing this a worksforme.