Video doesn't resume when MediaStreamTrack is removed and added. about react-native-webrtc HOT 8 OPEN

Thanks for getting to the bottom of it. By the looks it seems like a revert is the most sensible thing to do, while the investigation for the original issue continues.

from react-native-webrtc.

This is the only piece of code that deals with remoteTracks in the onAddTrack handler on Android (same on iOS FWIW):

            // We need to fire this event for an existing track sometimes, like
            // when the transceiver direction (on the sending side) switches from
            // sendrecv to recvonly and then back.
            final boolean existingTrack = remoteTracks.containsKey(track.id());

            if (!existingTrack) {
                if (track.kind().equals(MediaStreamTrack.VIDEO_TRACK_KIND)) {
                    videoTrackAdapters.addAdapter((VideoTrack) track);
                }
                remoteTracks.put(track.id(), track);
            }

The change was made by yours truly in 6df8357

Ssomething that just came to mind is that now we are removing the remote track from our map, but we are not disposing its adapter, in case it's a video track.

Turning this the other way around, @davidliu what problem were you fixing? AFAIS there is no way for track to not be set for a receiver: https://w3c.github.io/webrtc-pc/ So it feels like what we merged was more incorrect, generally speaking.

from react-native-webrtc.

Looking at the example code, this is caused by how it's ordered in the mediasoup library.

Consumer.pause():

1. track.enabled is set to false
2. onRemoveTrack gets called
   • Notably, the track is not removed from Consumer.

Consumer.resume()

1. track.enabled is set to true
   • Since the track is removed from our map, this call fails.
2. onAddTrack gets called after.

Not sure how MediaStreamTrack lifetimes are supposed to work, but I'm guessing it actually does stay alive in some form for browsers even after removal, which allows for this wonky call order.

@saghul I'll reinvestigate the original issue and get back to you.

from react-native-webrtc.

What does Consumer.pause do under the hood? Change the transceiver direction?

from react-native-webrtc.

https://github.com/versatica/mediasoup-client/blob/64298846a1d0b49f719b7665c93b6719722571d1/src/handlers/ReactNativeUnifiedPlan.ts#L1000

Sets the direction to inactive for the transceiver as well as the media object in the sdp (and then renegotiates).

from react-native-webrtc.

In that case I think the track won't disappear, if we inspect that receiver.

from react-native-webrtc.

Yeah, checked it and the receiver still has the track in this case.

For my original issue, the sender unpublished and republished an audio track with the same track id. In some instances, the setVolume call failed (unfortunately I wasn't able to personally repro it). The intention of the original PR was actually to refresh the cached remote track pointer reference to a new one when it came back in onAddTrack, and seemed to fix the issue.

from react-native-webrtc.

Thank you very much for all the work!

from react-native-webrtc.