Subject: [pm-dir] request for an RFC 6390 review of https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-01.txt

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

Hi PMDIR,

As a co-chair of XRBLOCK WG, I would like to request the an RFC 6390 review of https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-01.txt. This document is in WGLC until 9/4.

Thanks and Regards,

Dan

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 13 Aug 2015 08:49:18 -0400

Thanks for your request, Dan.

Who will volunteer to do this review?

Al
pmdir admin

> -----Original Message-----
> From: pm-dir [mailto:[email-masked]] On Behalf Of Romascanu,
> Dan (Dan)
> Sent: Thursday, August 13, 2015 8:47 AM
> To: [email-masked]
> Cc: [email-masked]; Benoit Claise ([email-masked]);
> [email-masked]
> Subject: [pm-dir] request for an RFC 6390 review of
> https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-01.txt
> 
> 
> Hi PMDIR,
> 
> As a co-chair of XRBLOCK WG, I would like to request the an RFC 6390
> review of https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-
> 01.txt. This document is in WGLC until 9/4.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> _______________________________________________
> pm-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pm-dir

---

From: Vinayak Hegde <[email-masked]>
Date: Thu, 13 Aug 2015 18:23:57 +0530

I can review this in a couple of days.

Thanks
Vinayak Hegde

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 13 Aug 2015 08:57:06 -0400

Thanks Vin!

(we're back in business. our automated search tools
have failed or lost connectivity, so we rely on review
requests or directorate members to make suggestions).

regards,
Al

> From: Vinayak Hegde [mailto:[email-masked]]
> Sent: Thursday, August 13, 2015 8:54 AM
> To: MORTON, ALFRED C (AL)
> Cc: Romascanu, Dan (Dan); [email-masked]; [email-masked]; Benoit
> Claise ([email-masked]); [email-masked]
> Subject: Re: [pm-dir] request for an RFC 6390 review of
> >> review of
> >> https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-

---

From: Qin Wu <[email-masked]>
Date: Fri, 14 Aug 2015 06:13:53 +0000

I am happy to review, but it looks this work has already been assigned. :-)

Regards!
-Qin Wu
-----邮件原件-----
发件人: pm-dir [mailto:[email-masked]] 代表 MORTON, ALFRED C (AL)
发送时间: 2015年8月13日 20:49
收件人: Romascanu, Dan (Dan); [email-masked]
抄送: [email-masked]; Benoit Claise ([email-masked]); [email-masked]
主题: Re: [pm-dir] request for an RFC 6390 review of https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-01.txt

Al
pmdir admin

---

From: Vinayak Hegde <[email-masked]>
Date: Mon, 17 Aug 2015 00:14:51 +0530

Hi Qin Wu, You can also review it. More eyes make better standards :)

Review Follows.

1. In section 3, where you describe loss concealment methods, I get
the impression after reading the draft that all frames are created
equal after reading the draft. Generally in video encoding there are
key frames[1] which are more important as they carry full information
and are not dependent on other frames so methods 3b and 3c would
require a lot of computation to reconstruct atleast parts of the
frame. This aspect is not emphasized in the draft.

2. Also in Section 3d (Error Resilient Encoding), there are two clear subparts
    a. You can have vector related extra metadata that can be used to
reconstruct the scene based on loss of primary data
    b. You can have bit-block level encoding like Reed-Solomon error
correction[2]
Both of these are different techniques so should be split under their
own subheadings.

3. Also it would be great to have some explanation of why frame freeze
was chosen for special treatment (in bit reservation)

4. In section 4.1 The definition of MIFP is confusing especially the
part where it says "after multiplying the fraction by 256"

5. In section 4.1 The definition of MCFP, did not get this part "which
loss concealment (using V) was applied" (Missing reference ?)

6. Same comment as above for definition of FFSC

Thanks
Vinayak

1. https://en.wikipedia.org/wiki/Video_compression_picture_types#Intra_coded_frames.2Fslices_.28I.E2.80.91frames.2Fslices_or_Key_frames.29
2. https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction

---

From: Qin Wu <[email-masked]>
Date: Mon, 17 Aug 2015 02:22:29 +0000

Your comments look good, Agree with your opinion.
here are a few additional comments:
1. Abstract
What are “those” in the abstract? RTCP XR Reporting Block or Block types?
What does "augment" stands for?
Suggest to make the following change
NEW TEXT:
“
This document defines a new RTCP XR Report Block that allows the
reporting of concealment metrics for video applications of RTP. This XR report block complete ones defined in RFC[7294].
”
2.Section 4, 1st paragraph, last sentence
What is “consistent point”? remove it?

3.Section 4, definition of " Mean Concealed Frame Proportion (MCFP) "
loss concealment (using V)? Suggest to make the following change:
Loss concealment method (depicted as “V” in the definition of “Video Loss Concealment Method Type”)
4. Section 7.3
To get in line with other XR Block related RFC, suggest the following change:
NEW TEXT:
“
   The contact information for the registrations is:

   RAI Area Directors

   [email-masked]
”
5. Appendix A:
s/incorporated into/applied to
What does “V” stand for? Please specify it clearly without dependency on the figure in this document, suggest the following change:
s/V/ Video Loss Concealment Method Type
6.Appendix A,bullet e:
"
      The concealed
      proportion of each video frame is obtained by dividing the number
      of concealed macroblocks from this video frame by the total
      macroblock number of the video frame, which is equivalent to
      taking the integer part after multiplying the fraction by 256.
"
Suggest the following change:
OLD TEXT:
"
which is equivalent to
taking the integer part after multiplying the fraction by 256
"
NEW TEXT:
"
multiplying the result of the division by
256, limiting the maximum value to 255 (to avoid overflow), and
taking the integer part.
"

-Qin
-----邮件原件-----
发件人: pm-dir [mailto:[email-masked]] 代表 Vinayak Hegde
发送时间: 2015年8月17日 2:45
收件人: MORTON, ALFRED C (AL)
抄送: [email-masked]; Romascanu, Dan (Dan); [email-masked]; Benoit Claise ([email-masked]); [email-masked]
主题: Re: [pm-dir] request for an RFC 6390 review of https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-01.txt

Review Follows.

1. In section 3, where you describe loss concealment methods, I get the impression after reading the draft that all frames are created equal after reading the draft. Generally in video encoding there are key frames[1] which are more important as they carry full information and are not dependent on other frames so methods 3b and 3c would require a lot of computation to reconstruct atleast parts of the frame. This aspect is not emphasized in the draft.

2. Also in Section 3d (Error Resilient Encoding), there are two clear subparts
    a. You can have vector related extra metadata that can be used to reconstruct the scene based on loss of primary data
    b. You can have bit-block level encoding like Reed-Solomon error correction[2] Both of these are different techniques so should be split under their own subheadings.

3. Also it would be great to have some explanation of why frame freeze was chosen for special treatment (in bit reservation)

4. In section 4.1 The definition of MIFP is confusing especially the part where it says "after multiplying the fraction by 256"

5. In section 4.1 The definition of MCFP, did not get this part "which loss concealment (using V) was applied" (Missing reference ?)

Thanks
Vinayak