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

Alan Clark <alan.d.clark@telchemy.com> Wed, 10 October 2012 09:02 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 276B121F8768 for <xrblock@ietfa.amsl.com>; Wed, 10 Oct 2012 02:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.527
X-Spam-Level: *
X-Spam-Status: No, score=1.527 tagged_above=-999 required=5 tests=[AWL=2.729, 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 VtejNo093QY5 for <xrblock@ietfa.amsl.com>; Wed, 10 Oct 2012 02:02:57 -0700 (PDT)
Received: from smtp01.myhostedservice.com (smtp01.myhostedservice.com [216.134.213.70]) by ietfa.amsl.com (Postfix) with ESMTP id 95BF221F876C for <xrblock@ietf.org>; Wed, 10 Oct 2012 02:02:56 -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; Wed, 10 Oct 2012 05:02:50 -0400
Received: from [192.168.1.5] (c-24-98-22-58.hsd1.ga.comcast.net [24.98.22.58]) by mail01.netplexity.net with SMTP; Wed, 10 Oct 2012 05:02:47 -0400
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 10 Oct 2012 05:02:49 -0400
From: Alan Clark <alan.d.clark@telchemy.com>
To: Qin Wu <bill.wu@huawei.com>
Message-ID: <CC9AB1F9.4ADF7%alan.d.clark@telchemy.com>
Thread-Topic: [xrblock] Loss-Type concealment vs Buffer adjustment type concealment
Thread-Index: Ac2mxgWFT0a8cZABrEGYggDE4e8d1Q==
In-Reply-To: <E193A85F953E4D11BE366591DBAC0818@china.huawei.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="B_3432690171_2075165"
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: Wed, 10 Oct 2012 09:02:59 -0000

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