Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05

[Qin Wu <[e-mail]>]

I am okay to change unit for threshold and reporting in the concealment seconds block.
What about loss concealment block? It looks you suggest to change 16 bit "Mean Playout Interrupt Size  "
And "Playout Interrupt Count  " into 32bit? Are I right?

Regards!
-Qin
From: [e-mail] [mailto:[e-mail]] On Behalf Of Kevin Gross
Sent: Tuesday, July 02, 2013 11:35 PM
To: Qin Wu
Cc: xrblock-chairs; Colin Perkins; xrblock
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05

I'm not suggesting a change to how SCS is measured. We would continue to use a 1 second measurement window. I'm proposing a change to the units for threshold (to allow a wider range) and the units used for reporting (to allow greater precision).

Using RTP timestamp units does require more care in sizing fields due to the different RTP clock rates used for different types of streams. The most demanding case I am aware of is RFC 3497 which uses a 148.5 MHz RTP clock. 16-bits is definitely not enough at this rate and 32-bits can even be insufficient to the extent that RFC 3497 breaks some basic RTP stuff and perhaps should be considered an outlier.

On the other hand, although there's a lot of precedent, I believe we need to be working away from time representations limited to 1 ms resolution. I don't often see a valid justification for arbitrarily limiting resolution and there are emerging cases where the additional precision is significant and useful. I still intend to write an I-D with timestamping recommendations but need to get my existing drafts (clksrc, leap-second) through the system before I can take this on. In the meantime, I will continue to bring this up in draft comments.

Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.X192.org>

On Mon, Jul 1, 2013 at 8:22 PM, Qin Wu <[e-mail]<mailto:[e-mail]>> wrote:
Hi, Kevin:

I have two difficulties to change measurement unit.
draft-ietf-xrblock-rtcp-xr-loss-conceal-05 defines two XR metrics blocks,one is loss concealment block, the other is concealment seconds block.
I think changing unit from milliseconds (ms) to RTP timestamp unit is more applicable to Loss Concealment Block than concealment seconds Block.

In the concealment seconds block, you are right, SCS threshold is better represented as a fraction 0/255 to 255/255,e.g., 5% of 1 seconds is 50ms.
However concealment seconds block is based on successive one second intervals as declared by a local clock and used to report the number of xxx seconds that occur. See 2nd paragraph of section 4, it said:
"
   The following metrics are based on successive one second intervals as
   declared by a local clock.  This local clock does NOT need to be
   synchronized to any external time reference.  The starting time of
   this clock is unspecified.  Note that this implies that the same loss
   pattern could result in slightly different count values, depending on
   where the losses occur relative to the particular one-second
   demarcation points.  For example, two loss events occurring 50ms
   apart could result in either one concealed second or two, depending
   on the particular 1000 ms boundaries used.

"
So are you suggesting concealment seconds not following 1 seond intervals decleared by the local clock?

In the loss concealment blocks, "Mean Playout Interrupt Size" is defined as 16bit field and uses "ms" as unit however
"On-time Playout Duration"," Loss Concealment Duration"," Buffer Adjustment Concealment Duration" are all defined
As 32bit fields and also use "ms" as unit. So if we change 32 bit fields unit from "ms" into RTP timestamp unit,
How about 16 bit "Mean Playout Interrupt Size" field?

Regards!
-Qin

From: Kevin Gross [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Sunday, June 30, 2013 11:24 PM
To: Qin Wu
Cc: Colin Perkins; xrblock-chairs; xrblock

Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05

I doesn't quite make sense to me.

It seems like reporting in RTP timestamp units would make things better for both the reporter and reportee. The reporter won't need to maintain a separate higher-precision counter and then do a conversion for reporting. (Or not implement a higher-precision counter and under report in the presence of frequent short events.) The reportee receives higher-precision reports.

SCS threshold might be better represented as a fraction 0/255 to 255/255. This resolves your mixed-units concern and allows a wider range of SCS behavior.

Kevin Gross
[phone]<tel:%2B1-303-447-0517>
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.X192.org>

On Wed, Jun 19, 2013 at 6:35 PM, Qin Wu <[e-mail]<mailto:[e-mail]>> wrote:
Thanks!

-----Original Message-----
From: Colin Perkins [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, June 20, 2013 1:20 AM
To: Qin Wu
Cc: Shida Schubert; xrblock-chairs; xrblock
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05

Qin,

Makes sense, thanks.

Colin



On 18 Jun 2013, at 04:20, Qin Wu wrote:
> Good points. I fully agree.
> However changing measurement unit from RTP timestamp unit to ms may cause measurement unit inconsistency.
>
> Taking loss concealment metrics block as an example, both 32 bit On-time Playout Duration field and 16 bit Mean Playout Interrupt Size uses the same measurement unit (ms), if we only change measurement unit for all 32 bit fields that carry loss concealment metrics to RTP timestamp unit, this cause
> Some fields in the block use "ms" as unit, some field uses RTP timestamp unit.
>
> Taking concealment seconds metrics as another example, "SCS Threshold" field also uses milliseconds as unit.
>
> Let me know what you think of this?
>
> Regards!
> -Qin
> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Tuesday, June 18, 2013 6:10 AM
> To: Qin Wu
> Cc: Shida Schubert; xrblock-chairs; xrblock
> Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05
>
> Qin,
>
> The length of time represented by an audio payload tends to be an integer number of milliseconds for frame-based codecs, but can have an arbitrary length for sample-based codecs. Using RTP timestamp units might allow you to precisely match up the timings, if that matters. Plus, don't you have RTP timestamp units, but would need to convert to milliseconds?
>
> Colin
>
>
>
> On 13 Jun 2013, at 06:34, Qin Wu wrote:
>> Colin,
>> Yes, you are right.
>> The length of time represented by audio playload in the RTP packet is usually measured using ms.
>> Another rationale is concealment metrics are just terminal related end system metrics and its calculation does not need to rely on RTP timestamp in the RTP packet.
>>
>> Regards!
>> -Qin
>> -----Original Message-----
>> From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Colin Perkins
>> Sent: Wednesday, June 12, 2013 12:02 AM
>> To: Shida Schubert
>> Cc: xrblock-chairs; xrblock
>> Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05
>>
>> Shida,
>>
>> I've read the draft, and believe it's in reasonable shape to progress. I would be interested in hearing the authors' rationale for choosing ms as the measurement unit rather than RTP timestamp units, however. It would seem that there might be an argument for using RTP timestamp units, so the reports can exactly line-up with the audio data in the RTP packets.
>>
>> Colin
>>
>>
>>
>> On 29 May 2013, at 17:53, Shida Schubert wrote:
>>> This is an announcement of a 2 weeks XRBLOCK WG last call on
>>> "Report Block for Concealment metrics Reporting on Audio Applications"
>>> prior to requesting publication of the document as a proposed standard.
>>>
>>> As per discussion at the last meeting, we are running a second
>>> WGLC on this draft.
>>>
>>> Please send your comments, including nits, to the list by the
>>>
>>> 12th of June
>>>
>>> If you read the draft and you see no issues, concerns, or nits, please
>>> express the fact that you have no issue progressing the draft on the
>>> list as well.
>>>
>>> The latest version can be found here:
>>>
>>> http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-loss-conceal-05
>>>
>>> Regards
>>>
>>> Shida as co-chair
>>> _______________________________________________
>>> xrblock mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/xrblock
>>
>>
>>
>> --
>> Colin Perkins
>> http://csperkins.org/

_______________________________________________
xrblock mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/xrblock