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

On 27/09/16 18:41, Bernard Aboba wrote:
> 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.

Yes, both of those methods are also available (in addition to the 
transceiver.stop() method).

Assuming we want to avoid negotiation for allowing the sending app to 
get a frozen video frame displayed at the video tag at the remote end, 
that basically leaves us with sender.setParameters().

Is that the way we should go? And in case of multicast, should the 
displayed video freeze if encoding[0] is inactive, if any of the 
encodings are inactive, or only if all of them are (assuming the 
receiving browser is able to receive simulcast)?

Or should we add a RtpSender global 'active' attribute? Or something else?

>
> ________________________________________
> 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 17:30:54 UTC