Re: [xrblock] Loss-Type concealment vs Buffer adjustment type concealment

Alan Clark <alan.d.clark@telchemy.com> Fri, 19 October 2012 12:21 UTC

Return-Path: <alan.d.clark@telchemy.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78E221F8620 for <xrblock@ietfa.amsl.com>; Fri, 19 Oct 2012 05:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.292
X-Spam-Level:
X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BcmRwLC9sQR for <xrblock@ietfa.amsl.com>; Fri, 19 Oct 2012 05:21:07 -0700 (PDT)
Received: from smtp01.myhostedservice.com (smtp01.myhostedservice.com [216.134.213.70]) by ietfa.amsl.com (Postfix) with ESMTP id D044421F8489 for <xrblock@ietf.org>; Fri, 19 Oct 2012 05:21:06 -0700 (PDT)
Received: from mail01.netplexity.net (172.29.251.14) by SMTP01.netplexity.local (172.29.211.9) with Microsoft SMTP Server id 14.0.722.0; Fri, 19 Oct 2012 08:20:48 -0400
Received: from [192.168.1.6] (c-24-98-22-58.hsd1.ga.comcast.net [24.98.22.58]) by mail01.netplexity.net with SMTP; Fri, 19 Oct 2012 08:20:57 -0400
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 19 Oct 2012 08:21:17 -0400
From: Alan Clark <alan.d.clark@telchemy.com>
To: Qin Wu <bill.wu@huawei.com>
Message-ID: <CCA6BDFD.4B2BF%alan.d.clark@telchemy.com>
Thread-Topic: [xrblock] Loss-Type concealment vs Buffer adjustment type concealment
Thread-Index: Ac2t9Dz2xfUDp19DzkC+Zmb31nOyyg==
In-Reply-To: <C01C5A2124A14536854F059558E95AA0@china.huawei.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="B_3433479682_18406015"
Cc: xrblock@ietf.org
Subject: Re: [xrblock] Loss-Type concealment vs Buffer adjustment type concealment
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Oct 2012 12:21:10 -0000

Hi Qin

There is an equivalent buffer adjustment behavior in video systems.  If
there is some need to increase or decrease the playout buffer size this can
be accommodated by either temporarily adjusting the frame rate or freezing/
skipping frames.  The extreme case of this is in a video streaming system
which can pause playout for 10-30 seconds if a buffer outage occurs -
typically the client will increase the playout buffer to allow for more
variability in network or server induced delays.

Best Regards

Alan


On 10/19/12 3:59 AM, "Qin Wu" <bill.wu@huawei.com> wrote:

> Hi,Alan:
> one follow up question is:
> Is Buffer adjustment type concealment applicable to video application?
> It seems Buffer Adjustment-type concealment is usually applied to audio.
>  
> Regards!
> -Qin
>>  
>> ----- Original Message -----
>>  
>> From:  Alan Clark <mailto:alan.d.clark@telchemy.com>
>>  
>> To: Qin Wu <mailto:bill.wu@huawei.com>
>>  
>> Cc: xrblock@ietf.org
>>  
>> Sent: Wednesday, October 10, 2012 5:20  PM
>>  
>> Subject: Re: [xrblock] Loss-Type concealment  vs Buffer adjustment type
>> concealment
>>  
>> 
>> Also - we should note that with video it is possible  to use RTP based
>> retransmission and also FEC (e.g. COP3) - typically these  would only be used
>> with IPTV as this is less delay sensitive than interactive  services.
>> 
>> Alan
>> 
>> 
>> On 10/10/12 5:02 AM, "Alan Clark" <alan.d.clark@telchemy.com>  wrote:
>> 
>>  
>>> Qin
>>> 
>>> The wording in  draft-ietf-xrblock-xr-consec-.. is definitely related to
>>> audio. Video does  have loss concealment and there are a range of methods
>>> used, for  example:
>>> 
>>> (i) Frame freeze
>>> In this case the impaired video frame is  not displayed and the previously
>>> displayed frame is hence ³frozen² for the  duration of the loss even
>>> 
>>> (ii) Inter-frame extrapolation
>>> If an  area of the video frame is damaged by loss, the same area from the
>>> previous  frame(s) can be used to estimate what the missing pixels would
>>> have been.   This can work well in a scene with no motion but can be very
>>> noticeable if there is significant movement from one frame to another.
>>> Simple decoders may simply re-use the pixels that were in the missing  are,
>>> more complex decoders may try to use several frames to do a more  complex
>>> extrapolation
>>> 
>>> (iii) Interpolation
>>> A decoder may use the  undamaged pixels in the image to estimate what the
>>> missing block of image  should have
>>> 
>>> (iv) Noise insertion
>>> A decoder may insert random pixel  values - which would generally be less
>>> noticeable than a blank rectangle in  the image
>>> 
>>> Alan
>>> 
>>> On 10/10/12 3:41 AM, "Qin Wu" <bill.wu@huawei.com>  wrote:
>>> 
>>>  
>>>> Hi,
>>>> In  draft-ietf-xrblock-rtcp-xr-concsec,concealment is splitted into two
>>>> type  of concealments.
>>>> One is Loss-Type concealment and the other is Buffer  adjustment type
>>>> concealment.
>>>> So the question is are these two type of  concealments applied to video? If
>>>> the answer is yes,
>>>> how to take video  loss concealment into account? Since in the current
>>>> draft, when we  define
>>>> Loss-type concealment and buffer adjustment type concealment,  only audio
>>>> loss concealment
>>>> is considered. See section 2.2 of  draft-ietf-xrblock-rtcp-xr-concsec below
>>>> for defintions of loss-type  concealment
>>>> and buffer adjustment type concealment:
>>>> "     
>>>>      Loss-type concealment  is reactive insertion or deletion of  samples
>>>>       in the audio playout stream  due to effective frame loss at  the
>>>>       audio decoder.  "Effective  frame loss" is the event in which  a
>>>>       frame of coded audio is simply  not present at the audio  decoder
>>>>       when required.  In  this case, substitute audio samples  are
>>>>       generally formed, at the  decoder or elsewhere, to reduce  audible
>>>>       impairment.
>>>> 
>>>>      Buffer  Adjustment-type concealment is proactive or  controlled
>>>>       insertion or deletion of  samples in the audio playout stream  due
>>>>       to jitter buffer adaptation,  re-sizing or re-centering  decisions
>>>>       within the endpoint.  Because this insertion is controlled, rather
>>>> than  occurring
>>>>       randomly in response to  losses, it is typically less audible  than
>>>>       loss-type concealment.   For example, jitter buffer  adaptation
>>>>       events may be  constrained to occur during periods of  talker
>>>>       silence, in which case only  silence duration is affected,  or
>>>>       sophisticated time-stretching  methods for  insertion/deletion
>>>>       during favorable  periods in active speech may be employed.   For
>>>>       these reasons, buffer  adjustment-type concealment MAY be  exempted
>>>>       from inclusion in  calculations of Concealed Seconds and  Severely
>>>>       Concealed  Seconds.
>>>> "
>>>> 
>>>> Regards!
>>>> -Qin 
>>>> 
>>>>  
>>>> 
>>>>  _______________________________________________
>>>> xrblock  mailing list
>>>> xrblock@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/xrblock
>>> 
>>>  
>>> 
>>>  _______________________________________________
>>> xrblock  mailing list
>>> xrblock@ietf.org
>>> https://www.ietf.org/mailman/listinfo/xrblock
>>  
>> 
>>  
>> 
>>  
>> 
>> _______________________________________________
>> xrblock mailing  list
>> xrblock@ietf.org
>> https://www.ietf.org/mailman/listinfo/xrblock
>>