- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Sat, 14 Nov 2020 11:36:05 +0000
- To: public-webrtc-logs@w3.org
I see, strictly speaking that does not exist either. And with regards to replacing one track with another track, you'll just change what frames are being sent, but nothing is negotiated to tell the other endpoint that the track was replaced. However, you can start or stop the transmission if you are using replaceTrack(null) and replaceTrack(track), which is different from enabling or disabling the track that is being sent - as that just replaces the content with black frames. RTCRtpSender.track: > The track attribute is the track that is associated with this RTCRtpSender object. If track is ended, or if the track's output is disabled, i.e. the track is disabled and/or muted, the RTCRtpSender MUST send black frames (video) and MUST NOT send (audio). In the case of video, the RTCRtpSender SHOULD send one black frame per second. If track is null then the RTCRtpSender does not send. On getting, the attribute MUST return the value of the [[SenderTrack]] slot. But so what happens if we start or stop sending? > Whenever an RTCRtpReceiver receives data on an RTP source whose corresponding MediaStreamTrack is muted, but not ended, and the [[Receptive]] slot of the RTCRtpTransceiver object the RTCRtpReceiver is a member of is true, it MUST queue a task to set the muted state of the corresponding MediaStreamTrack to false. > > When one of the SSRCs for RTP source media streams received by an RTCRtpReceiver is removed either due to reception of a BYE or via timeout, it MUST queue a task to set the muted state of the corresponding MediaStreamTrack to true. Note that setRemoteDescription can also lead to the setting of the muted state of the track to the value true. You should not expect to see an RTCP BYE, this only happens when the transmission ends permanently (e.g. RTCRtpTransceiver.stop()). But you should expect to see onmute fire after a timeout and onunmute to happen when receiving packets again. However... - I don't know what this timeout is supposed to be, and in either case it is not instant like you might expect. - It could also happen due to connectivity issues, so this is not a "replaceTrack" event. - Chromium-based browsers does not implement muting and unmuting properly, so it can't be relied upon on several of today's implementations. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2601#issuecomment-727193353 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 14 November 2020 11:36:08 UTC