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

[Qin Wu <[e-mail]>]

FYI.
-----邮件原件-----
发件人: Qin Wu 
发送时间: 2015年8月17日 10:22
收件人: 'Vinayak Hegde'; MORTON, ALFRED C (AL)
抄送: [e-mail]; Romascanu, Dan (Dan); [e-mail]; Benoit Claise ([e-mail]); [e-mail]
主题: RE: [pm-dir] request for an RFC 6390 review of https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-01.txt

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

   [e-mail]
”
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:[e-mail]] 代表 Vinayak Hegde
发送时间: 2015年8月17日 2:45
收件人: MORTON, ALFRED C (AL)
抄送: [e-mail]; Romascanu, Dan (Dan); [e-mail]; Benoit Claise ([e-mail]); [e-mail]
主题: Re: [pm-dir] request for an RFC 6390 review of https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-01.txt

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

On Thu, Aug 13, 2015 at 6:19 PM, MORTON, ALFRED C (AL) <[e-mail]> wrote:
> Thanks for your request, Dan.
>
> Who will volunteer to do this review?
>
> Al
> pmdir admin
>
>> -----Original Message-----
>> From: pm-dir [mailto:[e-mail]] On Behalf Of Romascanu, 
>> Dan (Dan)
>> Sent: Thursday, August 13, 2015 8:47 AM
>> To: [e-mail]
>> Cc: [e-mail]; Benoit Claise ([e-mail]); 
>> [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pm-dir
>
> _______________________________________________
> pm-dir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pm-dir

_______________________________________________
pm-dir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pm-dir