Re: [xrblock] Loss-Type concealment vs Buffer adjustment type concealment
Qin Wu <bill.wu@huawei.com> Wed, 10 October 2012 10:20 UTC
Return-Path: <bill.wu@huawei.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 A013421F84F1 for <xrblock@ietfa.amsl.com>; Wed, 10 Oct 2012 03:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.067
X-Spam-Level:
X-Spam-Status: No, score=-4.067 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
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 BRfxaLiSeoIA for <xrblock@ietfa.amsl.com>; Wed, 10 Oct 2012 03:20:09 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C74421F84EF for <xrblock@ietf.org>; Wed, 10 Oct 2012 03:20:08 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALM58571; Wed, 10 Oct 2012 10:20:06 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 10 Oct 2012 11:19:19 +0100
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 10 Oct 2012 11:19:35 +0100
Received: from w53375 (10.138.41.149) by szxeml402-hub.china.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 10 Oct 2012 18:18:54 +0800
Message-ID: <32A2BA0225FB460699C8BAED0DF8DBDC@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Alan Clark <alan.d.clark@telchemy.com>
References: <CC9AB1F9.4ADF7%alan.d.clark@telchemy.com>
Date: Wed, 10 Oct 2012 18:18:54 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_05F3_01CDA713.B4D1D4C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
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 10:20:10 -0000
Re: [xrblock] Loss-Type concealment vs Buffer adjustment type concealmentHi, Alan: That's a good summary for video loss concealment method. Please see my comments inline. ----- Original Message ----- From: Alan Clark To: Qin Wu Cc: xrblock@ietf.org Sent: Wednesday, October 10, 2012 5:02 PM Subject: Re: [xrblock] Loss-Type concealment vs Buffer adjustment type concealment 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 [Qin]: Agree, this method is also widely used technique in the IPTV deployment or cable TV deployment. (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 [Qin]: I think one example of inter-frame extrapoltion is motion-compensated repetition. Motion-compensated repetition is widely used techniques for video loss concealment and is used a repeat of the preceding frame to replace the part of the frame affected by the loss when loss occur. (iii) Interpolation A decoder may use the undamaged pixels in the image to estimate what the missing block of image should have [Qin]: Two examples of interpolation are repair in the spatial domain and repair in the frequency domain Repair in the spatial domain means relying on interpolation of a missing block, on the basis of the surrounding data. For example, the average pixel color for each of the surrounding blocks can be calculated, and the missing block can be set to the average of those colors. The similar techiques used in repair in the spatial domain can be applied to repair in the frequency domain.For example, for codecs based on the DCT, such as MPEG, H.261, and H.263. The low-order DCT coefficients can be averaged across the surrounding blocks, to generate a fill-in for a missing block. (iv) Noise insertion A decoder may insert random pixel values - which would generally be less noticeable than a blank rectangle in the image [Qin]: It looks to me Noise insertion also can be regarded as one kind of interpolation. At least, they have the similarity. For example,when interpolation using repair in the spatial domain, the average pixel color for each of the surrounding blocks is calculated to replace the missing block. In the Noise insertion, a random pixel color value is choosen for the missing block. 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] Loss-Type concealment vs Buffer adjustm… Qin Wu
- Re: [xrblock] Loss-Type concealment vs Buffer adj… Alan Clark
- Re: [xrblock] Loss-Type concealment vs Buffer adj… Alan Clark
- Re: [xrblock] Loss-Type concealment vs Buffer adj… Qin Wu
- Re: [xrblock] Loss-Type concealment vs Buffer adj… Qin Wu
- Re: [xrblock] Loss-Type concealment vs Buffer adj… Qin Wu
- Re: [xrblock] Loss-Type concealment vs Buffer adj… Alan Clark
- Re: [xrblock] Loss-Type concealment vs Buffer adj… Qin Wu