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: Wed, 28 Sep 2016 16:32:47 +0000
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <SN1PR21MB0030C91942B52047581404E7ECCF0@SN1PR21MB0030.namprd21.prod.outlook.com>
Stefan said: 

"Is that the way we should go? And in case of simulticast, 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?"

[BA] I would expect a "video freeze" to be displayed if a receiver stops receiving all video packets, however that happens. 

If the SFU is only sending a single video stream to the receiver, then freeze would occur if that stream ceases to be received (or there is very high loss that RTX/FEC cannot repair).  

If the sender stops sending an encoding to a receiver, that would not cause a freeze if there were other encodings being sent to that receiver , or the SFU decided to stop forwarding all encodings to that receiver.

If the receiver supported simulcast reception, it should not freeze video if it was receiving at least one encoding. 
Received on Wednesday, 28 September 2016 16:33:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:49 UTC