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

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

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 29 Sep 2016 12:46:41 +0000
To: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B4B06127C@ESESSMB209.ericsson.se>
On 28/09/16 18:32, Bernard Aboba wrote:
> 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.

To me the above makes sense, the question is what we need to spec, and 
where.

>
Received on Thursday, 29 September 2016 12:47:16 UTC

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