Closed Bug 881236 Opened 8 years ago Closed 6 years ago
Can't display video when no audio device is enabled in a Web
RTC peer connection
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130610 Firefox/23.0 (Nightly/Aurora) Build ID: 20130610004016 Steps to reproduce: 1. Started a WebRTC video call on https://apprtc.appspot.com/ 2. Joined to the meeting with an other participant with only video allowed Actual results: After the connection was established no video was displayed at the first participant. Expected results: Video was displaying without audio.
Component: Untriaged → WebRTC: Audio/Video
OS: Mac OS X → All
Product: Firefox → Core
This isn't a WebRTC bug - it's a bug in the apprtc app itself. Apprtc currently requires that both peers use audio/video together at all times or the call will fail per the media constraints specified here: http://code.google.com/p/webrtc-samples/source/browse/trunk/apprtc/index.html#120 So if one peer only grants access to video, but not audio, the call will fail since the mandatory constraints specified are not met. I double checked that my test app works which doesn't specify these constraints - it appears to work with one odd unrelated UI bug in Desktop Firefox. On that regard, I'm closing this as invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
Actually, my analysis above wasn't entirely correct after talking with Adam, although my claim that this is an apprtc bug is still valid. We're getting a JS error when this happens in their code, halting execution: [09:51:48.405] ReferenceError: event is not defined @ https://apprtc.appspot.com/js/main.js:431
I've seen that ReferenceError while apprtc was working. It seems to complain about a keyboard event, and I doubt it is related to AppRTC not working recently.
Okay, let's keep this open this for more investigation. FWIW though, I can reproduce this on apprtc on my own machine, but I can't reproduce this on my test app that does something similar to apprtc.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Too late to fix this on beta, but I did confirm this bug on my machine.
Ctangira says he can reproduce this on apprtc as well as with his own app. Myself I'm having trouble making a baseline LAN call with apprtc on Nightly today so I'm unable to confirm. Note when talking about this that constraints and permissions are different: Constraints are set by the webpage, permissions are set by the user. Perhaps due to this confusion, I just found the related but different Bug 917980.
If neither side allows audio, it appears not to connect. If one side does, one side appears to connect and the other hangs in "Initializing" on apprtc, but audio does flow in one direction. This was just a very fast test using two tabs in one browser. I didn't investigate why or any errors or warnings
Found the root cause and here's what's happening in theory: If Client_1 allows both video and audio, it expects both video and audio from the peer. Client_1: Start webrtc app and allows both Audio & Video. Creates new room, 0 Server_1: Sets the mExpectedTracks in DOMMediaStream to 0011 (because Client_1 is streaming both A and V). Client_2: Start webrtc app and allows only Video. Joins existing room = 0. Server_1: Client_2 starts to send media tracks (only video in this case). So it keep waiting for audio track and never sends the onaddstream callback. mExpectedTracks get set here: http://mxr.mozilla.org/mozilla-central/source/dom/media/MediaManager.h#297 Waits for expected tracks here: http://mxr.mozilla.org/mozilla-central/source/content/media/DOMMediaStream.cpp#332
Ok. To re-create with pc_test.html: 1. uncheck Use Fake Audio/Video 2. Start 3. Agree to audio+video for the first side 4. Agree to video only for the second. In the 2nd-side-to-1st-side (local image on left, large image on right) the local image will show, but the remote (large) image will not.
ctangira: thanks for tracking this down I think the problem is that gsmsdp_add_remote_track() is setting audio+video as hints, but we're actually only expecting to receive video and should know this from the SDP negotiation (i.e. the other side set port=0 to reject or set recvonly in response to our sendrecv offer.) gsmsdp_negotiate_media_lines() knows that the direction is SENDONLY and direction_supported is SENDRECV, so it should know we're not going to get a remote stream for this m= line.
We should ideally set the expected track types here: http://lxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp#400 Do we not know the types at this point?
If you know the track types there, you should call SetExpectedTracks with the right types before adding the callback. If you don't know the track types yet there, you should move the callback-adding code to a later point where you do know the types.
Is there a priority for this bug?
We killed hints...
Status: REOPENED → RESOLVED
Closed: 8 years ago → 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.