Re: [xrblock] New Version Notification for draft-huang-xrblock-rtcp-xr-video-lc-02.txt

Colin Perkins <csp@csperkins.org> Thu, 23 October 2014 21:05 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFB11AD362 for <xrblock@ietfa.amsl.com>; Thu, 23 Oct 2014 14:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkitZKsxSUct for <xrblock@ietfa.amsl.com>; Thu, 23 Oct 2014 14:05:15 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B2A1A1A93 for <xrblock@ietf.org>; Thu, 23 Oct 2014 14:05:13 -0700 (PDT)
Received: from [81.187.2.149] (port=46123 helo=[192.168.0.22]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1XhPZG-000851-An; Thu, 23 Oct 2014 22:05:11 +0100
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB8624A37E@nkgeml501-mbs.china.huawei.com>
Date: Thu, 23 Oct 2014 22:05:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <16978B15-3286-4D47-B326-CBB640A540FF@csperkins.org>
References: <51E6A56BD6A85142B9D172C87FC3ABBB862481E1@nkgeml501-mbs.china.huawei.com> <5C3DAF65-6FBD-4218-8DBD-AD292635CC04@csperkins.org> <51E6A56BD6A85142B9D172C87FC3ABBB862486CA@nkgeml501-mbs.china.huawei.com> <0FD01404-BEFB-4FF6-A0A1-B921FA726B52@csperkins.org> <51E6A56BD6A85142B9D172C87FC3ABBB8624A37E@nkgeml501-mbs.china.huawei.com>
To: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
X-Mailer: Apple Mail (2.1878.6)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/4VPyGLAZsocqrDKkGpk5ui6fudM
Cc: xrblock <xrblock@ietf.org>
Subject: Re: [xrblock] New Version Notification for draft-huang-xrblock-rtcp-xr-video-lc-02.txt
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 23 Oct 2014 21:05:18 -0000

Rachel,

On 23 Oct 2014, at 07:41, Huangyihong (Rachel) <rachel.huang@huawei.com> wrote:
> Hi Colin,
> 
> Please see inline.
> 
> BR,
> Rachel
> 
>> -----Original Message-----
>> From: Colin Perkins [mailto:csp@csperkins.org]
>> Sent: Thursday, October 23, 2014 6:57 AM
>> To: Huangyihong (Rachel)
>> Cc: xrblock
>> Subject: Re: [xrblock] New Version Notification for
>> draft-huang-xrblock-rtcp-xr-video-lc-02.txt
>> 
>> Hi Rachel,
>> 
>> On 20 Oct 2014, at 22:47, Huangyihong (Rachel) <rachel.huang@huawei.com>
>> wrote:
>>> Thanks for the comments. Please see inline.
>>> 
>>> BR,
>>> Rachel
>>> 
>>>> -----Original Message-----
>>>> From: Colin Perkins [mailto:csp@csperkins.org]
>>>> Sent: Monday, October 20, 2014 9:48 PM
>>>> To: Huangyihong (Rachel)
>>>> Subject: Re: [xrblock] New Version Notification for
>>>> draft-huang-xrblock-rtcp-xr-video-lc-02.txt
>>>> 
>>>> Rachel,
>>>> 
>>>> This looks to address many of my comments on the earlier versions,
>>>> thanks! I have some quick comments on this version:
>>>> 
>>>> Replacing retransmission in VLCM with Other Loss Concealment Method
>>>> is a good change.
>>>> 
>>>> The MIFP and MCFP fields are 8 bits, but use 0xFFFF (a 16 bit value)
>>>> to indicate an unavailable measurement; this should be 0xFF. You may
>>>> also consider whether these fields are better expressed as
>>>> fixed-point binary fractions, like the fraction lost field in RTCP RR
>>>> packets, rather than percentages, to use the full range of available values.
>>> 
>>> [Rachel]: Will fix it. Your suggestion makes sense to me.
>>>> 
>>>> Why are both loss free and impaired durations needed? Don't they sum
>>>> to the total duration of the call, meaning that one is redundant?
>>> 
>>> [Rachel]: No, there's difference. The metric of 'Loss impaired video image
>> duration' is the duration that still have impaired video pictures after applying
>> loss concealments. It's the time length that actually affects the end user's QoE.
>> We change 'loss concealed image duration' to it because we found that
>> 'Concealed Image Duration' was hard to measure since you don't know if it was
>> concealed or not.
>>> 'Loss impaired video image duration' <= total duration of the call - loss free
>> video image duration.
>> 
>> I'm still not sure I understand the difference. Do times when errors were
>> successfully concealed not count towards loss impaired duration?
> 
> [Rachel]: Yes. total duration of the call = loss free video image duration + totally concealed loss impaired duration + Loss impaired video image duration

Then, I think you need to improve the terminology. It’s not obvious that loss impaired duration excludes impaired duration where the loss was completely concealed.

>>>> The report block includes Impaired Image Duration and Mean Impaired
>>>> Frame Proportion, which are matching metrics, but Loss Free Image
>>>> Duration and Mean Concealed Frame Proportion, which don't match. If
>>>> Mean Concealed Frame Proportion is to be reported, the draft has to
>>>> report the corresponding Concealed Image Duration for consistency.
>>> 
>>> [Rachel]: See above. Do we have to keep the metrics consistency?
>> 
>> I do think consistency is important, but perhaps the issue is that I'm not
>> understanding what is meant by the loss impaired metric.
> 
> [Rachel]: Actually, MIFP and MCFP are not matched to duration metrics. They are calculated in Loss impaired video image duration, so that they could provide more information than just duration metrics for estimation of the concealment quality.

I’m suggesting that the mean duration and the total duration metrics should be paired.

Colin



-- 
Colin Perkins
https://csperkins.org/