Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added
Thank you for the update - and apologies for my delayed reply I have been dragged off onto other priorities, but will update once I get a chance to test your suggestions Thanks again for all the help ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added
It works for me when caller is on Chrome (m34) and Callee is on Firefox (v30 beta), and I have an WebRTC gateway in between. The things to look for are: 1. The offer should set OfferToReceiveVideo to true, resulting in an SDP with a=recvonly for video. 2. The answer SDP should have a=sendonly for video. 3. The onaddstream() should fire on Chrome, and in the handler, you should [re]attach the stream to the "remote view" video element (as when setRemoteDescription success callback happens, the remote stream might or might not be available). ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added
Thanks for the help so far, using the pc.getRemoteStreams()[0] in the setRemoteDescription success callback, solves all but 1 of my cases. Peer 1: Caller Peer 2: Callee FF (no video) FF (video) This works with Peer 1 seeing the video from Peer 2, and Peer 2 having no video (as Peer 1 is not broadcasting) However, putting Peer 1 on Chrome then Peer 1 does not receive the video from Peer 2, i.e. pc.getRemoteStreams()[0].getVideoTracks().length is 0 Looking at the SDP sent in the createAnswer callabck from Peer 2, both scenarios have m=video 12345 RTP/SAVPF. Any suggestions on how to investigate this further to determine where the video goes "missing"? Cheers ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added
On 5/14/14, 11:06 AM, ushunmu...@gmail.com wrote: Martin - I think you are talking about bug #998546. In my asymmetric call case, however, onaddstream never fires. As described in comment #2 in bug #998546 onaddstream never fires if no audio or video tracks are specified. My guess is that your problem is related. Nils ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added
Martin - I think you are talking about bug #998546. In my asymmetric call case, however, onaddstream never fires. ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added
On 2014-05-14, at 08:39, Brent Gracey wrote: > The setRemoteDescription callback is firing and pc.getRemoteStreams()[0] is > returning a stream, so I think I'll be able to use the work around Note that there is an open bug regarding the onaddstream event firing too late in Firefox. You should eventually get the event, but not before the setRemoteDescription callback. ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added
ah ha! nice The setRemoteDescription callback is firing and pc.getRemoteStreams()[0] is returning a stream, so I think I'll be able to use the work around Thanks for the pointers ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added
Given, RTCPeerConnection object is "pc", you could get the remote stream as follows: pc.getRemoteStreams()[0]. I suppose that there is a chance this value could be null if the stream isn't available. ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added
Thanks for your suggestion Uma. Could you share how you get the remote stream on the setRemoteDescription success callback? The callback doesn't get passed any parameters, and I can't see a way to create a mediaStream from a SDP (those where the two ways that I though might be an option) I was trying a different work around. Through my signalling channel, I am sharing which peers have video / audio, and setting OfferToReceive... based on if the peer was able to broadcast video / audio. This helped between two Firefox clients, where both had audio on and video off. I've tried to test each possible setup between chrome <-> chrome, firefox <->firefox, and chrome <-> firefox, with audio always on, and switching video on / off and am finding issues as below. # Caller Callee Works? a Chrome (no video) Chrome (no video) works bi Chrome (video) Chrome (no video)works bii Chrome (no video) Chrome (video) works ci FF (no video) FF (no video) works - with "dynamic" OfferToReceive di FF (no video) FF (video) does not work; dii FF (video) FF (no video) works ei Chrome (video) ff (video) works eii ff (video) Chrome (video) works fi Chrome (no video) FF (video) does not work; fii FF (video) Chrome (no video) does not work; gi Chrome (video) FF (no video) works gii FF (no video) Chrome (video) works hi Chrome (no video) ff (no video) works hii ff (no video) Chrome (no video) works ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
Re: onaddstream not called if {offerToReceiveVideo : true} and stream with no video added
I think this is not the correct behavior, given that the remote/answer SDP has video disabled (or set to recvonly). I have a slightly different problem, perhaps with the same underlying cause, where an asymmetric call is made between two FF instances. If the caller has both audio and video, and callee has only audio in their respective local stream, and an offer is made with both OfferToReceiveAudio/Video set to true, then the onaddstream is not fired on caller side after setRemoteDescription is called with the answer SDP (which correctly has a=recvonly for the video m-line). The remote audio wouldn't be played on the caller, as the app wouldn't attach the remote stream to the video element in this case. I use a workaround for this issue, however - on setRemoteDescription success callback, I still get and attach the remote stream to the video element, and audio is played fine. Thanks, Uma ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media
onaddstream not called if {offerToReceiveVideo : true} and stream with no video added
Hi, This is similar to the issue discussed here, but I couldn't find any relevant open bugs: https://code.google.com/p/webrtc/issues/detail?id=3004 I am testing between two ff browsers, and selecting the "Camera to share: no video" on the getUserMedia prompt in both browsers. If I set { 'OfferToReceiveVideo':true } in the SDP, the peer who creates the offer does not fire onaddstream when its remote description is set to a stream that is not sending video. If I change { 'OfferToReceiveVideo':false } - the callback is fired Is this expected behavior? Thanks, Brent ___ dev-media mailing list dev-media@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-media