1

Working with a native Android webRTC application and trying to remove the video track from the media stream which contains a combined audio/video (e.g., localMS.addTrack(peerConnectionFactory.createVideoTrack("ARDAMSv0", videoSource)); and localMS.addTrack(peerConnectionFactory.createAudioTrack("ARDAMSa0", audioSource)); ), the video stream is still sent to the remote end and there is no generation of the 'onrenegotiation' callback.

There is a lot of discussion about the removetrack versus the prior removestream functionality (e.g., see https://bugs.chromium.org/p/webrtc/issues/detail?id=5265#c4 or https://bugs.chromium.org/p/webrtc/issues/detail?id=2136 ), additionally, some work arounds are discussed such as removing the stream, then removing the track from the stream and adding the stream back again before creating a new offer. In the W3C standards (see http://w3c.github.io/mediacapture-main/#dfn-settings ), there does not appear to be a real indication that a renegotiation should occur.

The questions that i am trying to resolve are the following: Is this the correct way to remove a video track (i.e., call removetrack on the mediastream)?

Why does the onrenegotiation not occur? and if it does not occur when should a new offer be sent out?

Why does the calling of the removestream not actually stop the stream from being transmitted? (the transmission of a new offer itself would not appear to have any impact on the transmission of the stream only that the recipient has a recv_only in the sdp for that media component).

Any thoughts on any of this would be greatly appreciated and i will post whatever updates i come across and a working solution once resolved.

thanks

SBG
  • 357
  • 4
  • 17

1 Answers1

1

Not sure about Android WebRTC, but in browser WebRTC (which should be similar), you need to call stop() on the track to actually stop it. Or close the connection altogether.

You first add the track or a new stream and then create the offer and start the renegotiation process - it doesn't automatically start.

Adrian Ber
  • 20,474
  • 12
  • 67
  • 117
  • Thanks. In Android native webrtc (JNI MediaStreamTrackInterface) we have enable/disable of a track (but no stop) which results in sending a normal or black stream to the remote. If I disable the track and then call the remove I am not sure yet that the track is removed as the black screen still shows – but will test and update). With respect to the onnegotiation needed, per the W3C spec (sect. 4.8) it seems that is should fire on track added or stopped. Unclear to me why removing a track does not actually result in the track being removed from the stream regardless of whether stopped or not. – SBG Jun 09 '16 at 13:16
  • Also, will upgrade to the latest libjingle version (currently on one from August 2015), in which this might be fixed - will take a couple days as multiple changes throughout webrtc – SBG Jun 09 '16 at 18:15