W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2013

Re: Improving disconnection handling

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Thu, 11 Apr 2013 12:55:20 -0400
Message-ID: <5166EAF8.3060105@bbs.darktech.org>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 11/04/2013 12:09 AM, Martin Thomson wrote:
> On 10 April 2013 18:48, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>      I don't like users staring at a "frozen" image for five seconds. If I
>> had a way of finding out when the last video frame was received, I would
>> fade out the video immediate after it begins hanging and fade it back in
>> when it reconnects. What do you think?
> I think that you need to work on a precise definition of "begins
> hanging" such that it could be detected.  You might also find that a
> fadeout over such a short lapse is more annoying to your users than
> you think.  There may be a way of getting the time of the last
> rendered update, but keep in mind that the time for the video will
> probably be based on the sender clock, which can drift in relation to
> the local clock.  You really don't want false positives.

Hi Martin,

     If WebRTC would tell me the time (using the local clock) that the 
last video frame arrived then I could begin fading out the video after, 
say, 500ms. I'm not worried about false positives for two reasons:

 1. The video is supposed to be streaming at 30fps. If I haven't
    received a video frame in 300-500ms then something is seriously wrong.
 2. If the video fades out slowly enough, false positives won't be
    visible to the naked eye (opacity might change by 5% before the
    connection is recovered and opacity returns to normal).

Gili
Received on Thursday, 11 April 2013 16:56:10 UTC

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