W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2016

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

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Tue, 27 Sep 2016 16:41:06 +0000
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <DM2PR21MB0026A4921E1DA53BAE8A89C4ECCC0@DM2PR21MB0026.namprd21.prod.outlook.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:19 UTC