RE: video track "black" vs. "frozen frame"

With respect to an encoding, we have RTCRtpEncodingParameters.active. 

This can be manipulated as shown in Example 2: 

var params = sender.getParameters();
// ... make changes to RTCRtpParameters
params.encodings[0].active = false;
sender.setParameters(params)

There is also transceiver.setDirection(), but that sets the negotiation-needed flag.

________________________________________
From: Stefan Håkansson LK [stefan.lk.hakansson@ericsson.com]
Sent: Tuesday, September 27, 2016 3:59 AM
To: public-webrtc@w3.org
Subject: video track "black" vs. "frozen frame"

We talked about this in Lisbon,

and I recall us saying something like, in a situation where we have a

MST -> RtpSender -> RtpReceiver -> MST -> <video element>

(MST == MediaStreamTrack) setup, that the video element should:

* Render black if the send side MST was disabled (or muted upstream)
* Render a frozen video frame if the RtpSender was "stopped"

Is this correct?

And if so, my question is: How to stop the sender? There is no .stop()
method. The RtpTransceiver has a .stop() method, but that would also
stop the local RtpReceiver, which may not be desirable, and would not
have any action until after a negotiation.

Bernard mentions [1] "active=false", but it is a long time since we had
"active" on RtpSenders. It seems like that would be a good fit though.


[1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2016%2F09%2F23-webrtc-minutes%23item09&data=01%7C01%7CBernard.Aboba%40microsoft.com%7Cd77b3e8975e2463d872f08d3e6c5d673%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=SEdqyuBZMFQBDYnS5UngVQZQDe5AuOVfsyXqiWTQO2A%3D&reserved=0

Stefan

Received on Tuesday, 27 September 2016 16:41:36 UTC