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

Qin Wu <bill.wu@huawei.com> Wed, 10 October 2012 10:21 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 79F7E21F871A for <xrblock@ietfa.amsl.com>; Wed, 10 Oct 2012 03:21:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Level:
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, 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 fQVkzsGoGVFn for <xrblock@ietfa.amsl.com>; Wed, 10 Oct 2012 03:21:13 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFED21F84EF for <xrblock@ietf.org>; Wed, 10 Oct 2012 03:21:12 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALM58685; Wed, 10 Oct 2012 10:21:11 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 10 Oct 2012 11:20:41 +0100
Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 10 Oct 2012 18:21:11 +0800
Received: from w53375 (10.138.41.149) by szxeml407-hub.china.huawei.com (10.82.67.94) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 10 Oct 2012 18:21:05 +0800
Message-ID: <207C6CAE67F54675991505AAE607881F@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Alan Clark <alan.d.clark@telchemy.com>
References: <CC9AB61A.4ADF9%alan.d.clark@telchemy.com>
Date: Wed, 10 Oct 2012 18:21:05 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0626_01CDA714.02B56800"
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:21:14 -0000

Re: [xrblock] Loss-Type concealment vs Buffer adjustment type concealmentAgree.
  ----- Original Message ----- 
  From: Alan Clark 
  To: Qin Wu 
  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