No video self view on Nightly when using the WebRTC test page on Windows 8

NEW
Unassigned

Status

()

4 years ago
4 years ago

People

(Reporter: RT, Unassigned)

Tracking

unspecified
x86_64
Windows 8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

4 years ago
Environment: Windows 8 on Lenovo X1 Carbon, Firefox Nightly 39.0a1

Steps to reproduce
1 Get to http://mozilla.github.io/webrtc-landing/gum_test.html and click video
2 At Gum prompt select "Share integrated camera"
3 The page says "Success" although no self view is shown on the page (white area)

Browser console logs: http://pastebin.com/z8jBQee7

I have the same behavior when using Hello or talky.io.
Hi RT, I can't repro this on my Windows box; so I suspect it's something about your camera or your system -- or possibly there's another app on your machine holding the camera?

To debug, I'll need getUserMedia logs: https://wiki.mozilla.org/Media/WebRTC/Logging describes how to set them.  (I just need the gUM logs.)   

As a simple test (before grabbing the logs), you could restart Firefox and/or your PC to see if that solves the problem;  if it does, it's most likely that another app grabbed your camera, thus preventing Firefox from getting it.
Flags: needinfo?(rtestard)
(Reporter)

Comment 2

4 years ago
Maire, apologies for the delay here.
It's not another app - when I use Firefox GA it works.
It's unlikely a driver issue since it works with GA.
Same issue happens after restart.

I attach the logs. The steps I followed were:
- Go to about:webrtc and Start debug mode
- Open a conversation - The camera light turns on, the "room joined" bleep happens but the self view remains black
- Wait 10/15s
- Disconnect
- Stop debug mode
Flags: needinfo?(rtestard)
(Reporter)

Comment 3

4 years ago
Created attachment 8589596 [details]
WebRTC.log
(Reporter)

Comment 4

4 years ago
Maire and Shell, any chance of an update on this?
FYI this is now affecting the 38.0.1 GA build on my machine and the issue seems fixed on Nightly and dev edition
I am not sure if this is specific to my environment only, in this case I am happy to close as WON'T FIX since it seems that coming versions don't have the issue anymore anyway.
Flags: needinfo?(sescalante)
Flags: needinfo?(mreavy)
We landed some patches (and uplifted them to 38) which I expected would fix this; can you re-run the logs in 38 and 39 (beta)?

Due to jib's bug 1150539, in your logs it selected  960x540@10fps in format 2 (yuv); while not optimal that should work.  No frames were ever received from the camera, so this mode might simply be broken in the driver.  On 38.0.1, also can you try setting media.navigator.video.default_width to 640 and media.navigator.video.default_height to 480 and media.navigator.video.default_minfps to 30 and try again with logs.

Note jib's bug has been approved for 38.0.5, but has not landed there yet.
Flags: needinfo?(sescalante)
Flags: needinfo?(rtestard)
Flags: needinfo?(mreavy)
(Reporter)

Comment 6

4 years ago
Created attachment 8607417 [details]
WebRTC.log on GA 38.01
Flags: needinfo?(rtestard)
(Reporter)

Comment 7

4 years ago
Created attachment 8607424 [details]
WebRTC.log on Beta 38.0.5
(Reporter)

Comment 8

4 years ago
Thanks Randell
I have re-run the logs on 38.01 (GA) and 38.05 without config changes (Beta - not sure why I don't get 39 as Beta but 38.05 seems to be the most up to date Beta) - the same issue persists on both.

With config changes, on 38.01 it does work fine - sounds like you're right that it may be a driver issue where the resolution is not supported.
(Reporter)

Comment 9

4 years ago
Created attachment 8607432 [details]
WebRTC.log on GA 38.01 with config changes
Rank: 25
Priority: -- → P2
Our current assessment is this is a driver issue that we can't do anything about.
backlog: --- → parking-lot
Rank: 25
Priority: P2 → --
You need to log in before you can comment on or make changes to this bug.