[xrblock] Loss-Type concealment vs Buffer adjustment type concealment
Qin Wu <bill.wu@huawei.com> Wed, 10 October 2012 07:42 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 6111621F873C for <xrblock@ietfa.amsl.com>; Wed, 10 Oct 2012 00:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.078
X-Spam-Level:
X-Spam-Status: No, score=-4.078 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 C2GRPGxpEKMf for <xrblock@ietfa.amsl.com>; Wed, 10 Oct 2012 00:42:14 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E446221F873B for <xrblock@ietf.org>; Wed, 10 Oct 2012 00:42:13 -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 ALM42408; Wed, 10 Oct 2012 07:42:13 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 10 Oct 2012 08:41:42 +0100
Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 10 Oct 2012 08:41:57 +0100
Received: from w53375 (10.138.41.149) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 10 Oct 2012 15:41:53 +0800
Message-ID: <E193A85F953E4D11BE366591DBAC0818@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: xrblock@ietf.org
Date: Wed, 10 Oct 2012 15:41:52 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0424_01CDA6FD.C4ACAD40"
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
Subject: [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 07:42:15 -0000
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] 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