Subject: [xrblock] WGLC for 'RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications'

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 Aug 2015 12:41:37 +0000

We start a Working Group Last Call for the document 'RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications'. Please let us know if you believe that this document is ready to be submitted to the IESG for consideration as Proposed Standard. Please send your comments, questions and concerns to the WG mail list before September 4, 2015. If you have read the document and you did not find any problems your input is also welcome. If you are aware about any relevant IPR please take the appropriate actions as per RFC 3979.

The document is available at https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-01.txt.

Thanks and Regards,

Dan

---

From: "Roni Even" <[email-masked]>
Date: Thu, 20 Aug 2015 07:13:26 +0300

Hi,

I reviewed the document and it looks ready.

Two nits:

1.       Section 3 c "A decoder may user the undamaged pixels" should be "A
decoder may use the undamaged pixels.

2.       Section 6 second paragraph "which will be affect the estimation"
should be "which will affect the estimation"

Roni Even

From: xrblock [mailto:[email-masked]] On Behalf Of Romascanu, Dan
(Dan)
Sent: Thursday, August 13, 2015 3:42 PM
To: xrblock
Subject: [xrblock] WGLC for 'RTCP XR Report Block for Loss Concealment
Metrics Reporting on Video Applications'

We start a Working Group Last Call for the document 'RTCP XR Report Block
for Loss Concealment Metrics Reporting on Video Applications'. Please let us
know if you believe that this document is ready to be submitted to the IESG
for consideration as Proposed Standard. Please send your comments, questions
and concerns to the WG mail list before September 4, 2015. If you have read
the document and you did not find any problems your input is also welcome.
If you are aware about any relevant IPR please take the appropriate actions
as per RFC 3979. 

The document is available at
https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-01.txt.

Thanks and Regards,

Dan

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 20 Aug 2015 05:37:00 +0000

Thank you, Roni. They will be fixed in the next version.

BR,
Rachel

From: xrblock [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Thursday, August 20, 2015 12:13 PM
To: 'Romascanu, Dan (Dan)'; 'xrblock'
Subject: Re: [xrblock] WGLC for 'RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications'

Hi,

1.       Section 3 c "A decoder may user the undamaged pixels" should be "A decoder may use the undamaged pixels.

2.       Section 6 second paragraph "which will be affect the estimation" should be "which will affect the estimation"

Roni Even

From: xrblock [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, August 13, 2015 3:42 PM
To: xrblock
Subject: [xrblock] WGLC for 'RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications'

Thanks and Regards,

Dan

---

From: Colin Perkins <[email-masked]>
Date: Thu, 27 Aug 2015 15:35:37 +0100

On 13 Aug 2015, at 13:41, Romascanu, Dan (Dan) <[email-masked]> wrote:
> We start a Working Group Last Call for the document ‘RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications'. Please let us know if you believe that this document is ready to be submitted to the IESG for consideration as Proposed Standard. Please send your comments, questions and concerns to the WG mail list before September 4, 2015. If you have read the document and you did not find any problems your input is also welcome. If you are aware about any relevant IPR please take the appropriate actions as per RFC 3979.
>  

I think this is generally in good shape, but some of the definitions at the start of section 4 are unclear. Comments follow:

Section 1.1 uses "MUST" before the RFC 2119 terms have been defined.

Section 4: the first paragraph of this section says twice that a video loss concealment report block SHOULD be sent in the same packet as a Measurement Information Block. It probably only needs to say this once.

Section 4: the first paragraph, says that the video loss concealment report block "SHOULD be sent in the same packet as a Measurement Information Block", then says that the video loss concealment report "MUST be discarded" if the measurement period, included in the Measurement Information Block is not present. The later "MUST" seems to contradict the earlier "SHOULD" strength requirement. 

Section 4: the description of the fields following Figure 1 does not mention the RSV field. 

Section 4: some fields are defined as being measured in RTP timestamp units. Which RTP timestamp is used here? That used by the sender of the video loss concealment block, or that used by the source on which it is reporting?

The following lines contain uses of lower-case RFC 2119 keywords, which could cause confusion:

129:   endpoint or terminal may not see loss occurring between the probe and
130:   the endpoint, and may also not be fully aware of the specific loss
198:   another. Simple decoders may simply re-use the pixels that were in
199:   the missing area while more complex decoders may try to use several
207:   A decoder may user the undamaged pixels in the video frame to
208:   estimate what the missing block of pixels should have.
212:   The sender may encode the message in a redundant way so that receiver
216:   encoder may select a crucial area of an original video frame, extract
248:   discarded. It should be noted that the metrics in this report block
268:   |                  Mean Frame Freeze Duration (optional)        |
367:      Mean Frame Freeze Duration shall be calculated by summing the
369:      number of events. This metric is optional. It only exists
384:      a video frame is totally lost, a value of 0xFF shall be used for
408:      macroblocks, a value of 0, shall be used for the frame when
465:   An attacker may put incorrect information in the Video Loss
468:   Implementers should consider the guidance in [RFC7202] for using
470:   the implementation should apply encryption and authentication to the
658:      frame is decoded and rendered for playout. The metric shall be
700:      video frame is totally lost, a value of 0xFF shall be used for the
742:      there are no concealed macroblocks, a value of 0, shall be used

I suggest the text is either rephrased to avoid these, or they are replaced by the upper-case versions.

I didn't check the appendix.

Cheers,
Colin

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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 28 Aug 2015 02:38:01 +0000

Hi Colin,

Thank you for your careful review. Please see some of my replies inline.

BR,
Rachel

> -----Original Message-----
> From: xrblock [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: Thursday, August 27, 2015 10:36 PM
> To: Romascanu, Dan (Dan)
> Cc: xrblock
> know if you believe that this document is ready to be submitted to the IESG for
> consideration as Proposed Standard. Please send your comments, questions
> the document and you did not find any problems your input is also welcome. If
> you are aware about any relevant IPR please take the appropriate actions as
> per RFC 3979.
> >

[Rachel]: Right. I'll change it to lower-case.

> 
> Section 4: the first paragraph of this section says twice that a video loss
> concealment report block SHOULD be sent in the same packet as a
> Measurement Information Block. It probably only needs to say this once.

[Rachel]: I'll keep the first one and delete the latter sentence.

> 
> Section 4: the first paragraph, says that the video loss concealment report
> block "SHOULD be sent in the same packet as a Measurement Information
> Block", then says that the video loss concealment report "MUST be discarded"
> if the measurement period, included in the Measurement Information Block is
> not present. The later "MUST" seems to contradict the earlier "SHOULD"
> strength requirement.

[Rachel]: The first "SHOULD" refers to the sender, while the latter "MUST" refers to the receivers. Maybe I should add some clarifications to this sentence?

> Section 4: the description of the fields following Figure 1 does not mention the

[Rachel]: Right. Will fix it in the next version.

> 
> Section 4: some fields are defined as being measured in RTP timestamp units.
> Which RTP timestamp is used here? That used by the sender of the video loss
> concealment block, or that used by the source on which it is reporting?

[Rachel]: It should be measured by the sender of the reporting block, so it's the RTP timestamp used by the sender of the reporting block. I all add some clarification words to it in the next version.

> I suggest the text is either rephrased to avoid these, or they are replaced by

[Rachel]: Okay. I'll look through the whole text and fix them.

> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Colin Perkins <[email-masked]>
Date: Fri, 28 Aug 2015 10:05:11 +0100

Hi Rachel,

A brief follow-up below...

> [Rachel]: The first "SHOULD" refers to the sender, while the latter "MUST" refers to the receivers. Maybe I should add some clarifications to this sentence?

No, that's not the problem I had. If you say "SHOULD sent with a measurement info block", that implies that there are some valid reasons why you might not send it with the measurement info. But, you then say "MUST discard if not sent with a measurement info block". If it has to be discarded if the measurement info block is not present, what are the reasons for sending it without the measurement info? Either the "SHOULD be sent" has to change to "MUST be sent", or the "MUST be discarded" has to be relaxed to explain how the reporting period is inferred if the measurement info is not present.

Colin

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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 28 Aug 2015 09:28:52 +0000

Hi Colin,

Your comment makes sense to me. I'll change it to "MUST" to keep it simple, since the metrics may not have so much meanings if reporting period is estimated when the measurement info is not present. What do you think?

BR,
Rachel

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Friday, August 28, 2015 5:05 PM
> To: Huangyihong (Rachel)
> Cc: Romascanu, Dan (Dan); xrblock
> >> Subject: Re: [xrblock] WGLC for 'RTCP XR Report Block for Loss
> >> Concealment Metrics Reporting on Video Applications'
> >>
> >>> We start a Working Group Last Call for the document 'RTCP XR Report
> Block for Loss Concealment Metrics Reporting on Video Applications'. Please
> let us know if you believe that this document is ready to be submitted to the
> IESG for consideration as Proposed Standard. Please send your comments,
> questions and concerns to the WG mail list before September 4, 2015. If you
> have read the document and you did not find any problems your input is also
> welcome. If you are aware about any relevant IPR please take the appropriate
> actions as per RFC 3979.
> >>>
> >> I think this is generally in good shape, but some of the definitions
> >> at the start of section 4 are unclear. Comments follow:
> >>
> >> Section 4: the first paragraph of this section says twice that a
> >> video loss concealment report block SHOULD be sent in the same packet
> >> as a Measurement Information Block. It probably only needs to say this
> once.
> >
> >> Section 4: the first paragraph, says that the video loss concealment
> >> report block "SHOULD be sent in the same packet as a Measurement
> >> Information Block", then says that the video loss concealment report "MUST
> be discarded"
> >> if the measurement period, included in the Measurement Information
> >> Block is not present. The later "MUST" seems to contradict the earlier
> "SHOULD"
> >> strength requirement.
> >
> > [Rachel]: The first "SHOULD" refers to the sender, while the latter "MUST"
> refers to the receivers. Maybe I should add some clarifications to this
> sentence?
> 
> No, that's not the problem I had. If you say "SHOULD sent with a measurement
> info block", that implies that there are some valid reasons why you might not
> send it with the measurement info. But, you then say "MUST discard if not sent
> with a measurement info block". If it has to be discarded if the measurement
> info block is not present, what are the reasons for sending it without the
> measurement info? Either the "SHOULD be sent" has to change to "MUST be
> sent", or the "MUST be discarded" has to be relaxed to explain how the
> reporting period is inferred if the measurement info is not present.
> 
> Colin
> 
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 28 Aug 2015 10:42:36 +0100

Rachel,

Works for me.
Colin

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