1

After updating firefox to the last version (40), my WebRTC code stopped working when video wasn't available in firefox. After digging up a bit, I saw that videoTrack's lenght is 1, even when video is not being sent.

This function is placed in peerconnectionclient.js:

peerConnectionClient.prototype.onSetRemoteDescriptionSuccess_ = function() {

var remoteStreams = this.pc_.getRemoteStreams();
if (this.onremotesdpset) {
    this.onremotesdpset(remoteStreams.length > 0 && remoteStreams[0].getVideoTracks().length > 0);   
 }
};

Before firefox 40, remoteStreams[0].getVideoTracks().length was 0, when the remote client was not sending video. Now, videotracks lenght is 1.

What is more, videoTrack's readyState value is ="mute", which was removed from the specifications a while ago. Is this a bug? If so,how can I fix this? I have read an article that could be related with this issue https://hacks.mozilla.org/category/webrtc/as/complete/

moarra
  • 565
  • 1
  • 7
  • 20
  • You're not showing the code that sets this up, and the problem doesn't reproduce for me. A change in 40 that might affect you, or it might not, is that `onnegotiationneeded` is now fired in response to calling `pc.addStream` (or `pc.addTrack`) even before a connection has been established, whereas before it wasn't. Not seeing your setup I don't know if that matters. Also, are you using a third-party library? I ask because of [this bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1019579). Does `onaddstream` fire? – jib Aug 20 '15 at 11:43
  • Hello jib. I'm using this code: https://github.com/webrtc/apprtc, to be precise, im reusing the adapter and peerconnectionclient. OnAddStream is fired, the problem that the stream has incorrect values when one of the browsers is not using video. When firefox (just audio), chrome (video): -firefox doesnt not receive any video stream at the beginning, so it doe not wait for media to arrive - chome hangs waiting for video to arrive: it will never arrive because firefox has just audio I think, it should be just the oposite. @jib, which part of the setup? – moarra Aug 20 '15 at 21:49
  • Try giving these [RTCOfferOptions](http://w3c.github.io/webrtc-pc/#idl-def-RTCOfferOptions) to `createOffer`: `{ offerToReceiveVideo: true, offerToReceiveAudio: true }`. See [this other answer](http://stackoverflow.com/a/32039141/918910). – jib Aug 20 '15 at 22:23
  • The options are set as you said: mediaConstraints: { 'audio': true, 'video': { 'optional': [{ 'minWidth': '1280' }, { 'minHeight': '720' }], 'mandatory': {} } }, offerConstraints: { 'optional': [], 'mandatory': { 'OfferToReceiveAudio': true, 'OfferToReceiveVideo': true } } – moarra Aug 21 '15 at 07:43
  • Sigh, I see apprtc still uses non-standard constraints (`optional` and `minWidth`) which [wont do anything in Firefox](http://stackoverflow.com/a/28911694/918910), as well as obsolete createOffer options syntax, which [both Chrome and Firefox have deprecated](http://stackoverflow.com/a/30982333/918910) & will soon stop working in Firefox Nightly. With the latest [adapter.js](https://github.com/webrtc/adapter) there's no reason not to use the spec. - All that said, this should still work, and apprtc wfm in 40. Please post a question with a smaller code sample that shows the problem. – jib Aug 22 '15 at 04:21
  • I have corrected the mediaCosntraints and offerConstraints. However, the problem is not solved. This are the offers that chrome (video+ audio permission), firefox (just audio permission): In the sdp offer that firefox receives from chrome, I see both audio and video information, however, after setting remote session description, it says there is not remote video stream, so it does not wait for media to arrive. Chrome,receives both video an audio info in the offer( I don't know if it should receive video info if the permission hasnt been granted). Chrome detects a videotrack so it waits to it. – moarra Aug 22 '15 at 09:40
  • Do you want me to edit the question or post another one? – moarra Aug 22 '15 at 09:40
  • I'll leave that up to you. – jib Aug 22 '15 at 15:27
  • Hi Jib, I have solved the problem. By the way, these RTCOfferOptions createOffer: { offerToReceiveVideo: true, offerToReceiveAudio: true }, are not working on chrome to chrome calls. It throws an error when creating the answer to de offer. – moarra Aug 23 '15 at 14:32
  • Which error? RTCOfferOptions were implemented in Chrome [a year ago](https://code.google.com/p/webrtc/source/detail?r=6822). – jib Aug 24 '15 at 00:50
  • createanswer called with invalid constraints, when I use offerToReceiveVideo and offerToReceiveAudio instead OfferToReceiveVideo and OfferToReceiveVideo. – moarra Aug 24 '15 at 15:42
  • They are *offer* options, not answer options. Don't use them with `createAnswer`. – jib Aug 24 '15 at 17:10
  • Im just following the appRTC code, which uses these constraints, and I have not modified the code: PeerConnectionClient.DEFAULT_SDP_CONSTRAINTS_ = { 'mandatory': { 'OfferToReceiveAudio': true, 'OfferToReceiveVideo': true }, 'optional': [{ 'VoiceActivityDetection': false }] }; p = this.pc_.createAnswer(PeerConnectionClient.DEFAULT_SDP_CONSTRAINTS_); – moarra Aug 24 '15 at 20:43
  • what's stopping you? – jib Aug 24 '15 at 21:00

0 Answers0