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

From: Qin Wu <[email-masked]>
Date: Wed, 9 Sep 2015 01:11:01 +0000

FYI.
-----邮件原件-----
发件人: 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

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) <[email-masked]> wrote:
> 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
>
> _______________________________________________
> pm-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pm-dir

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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 9 Sep 2015 06:33:10 +0000

HI Vinayak,

Thank you for the review. Please see my answers inline.

BR,
Rachel

> From: Qin Wu
> Sent: Wednesday, September 09, 2015 9:11 AM
> To: Huangyihong (Rachel); [email-masked]; [email-masked]
> Cc: Romascanu, Dan (Dan); MORTON, ALFRED C (AL)
> Subject: RE: [pm-dir] request for an RFC 6390 review of
> 抄送: [email-masked]; Romascanu, Dan (Dan); [email-masked]; Benoit
> Claise ([email-masked]); [email-masked]
> 主题: Re: [pm-dir] request for an RFC 6390 review of
> 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.

[Rachel]: Yes, you're right the method 3b. How about adding a sentence in method 3b like this: "Some important frames, such as IDR frames, may not depend on any other frames and may be involved in a scene change. Using inter-frame extrapolation method to conceal the loss of these frames may not present a quite satisfactory result." However, for method 3c, it is a intra-frame concealment. It only happens inside one frame. So IMO I don't think they need to distinguish the different I or B or P frames. They are all treated as the same.

>     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.

[Rachel]: Okay. 

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

[Rachel]: How about changing 

" In this document, we differentiate between frame freeze and the other
   3 concealment mechanisms described. "
To

" Usually, methods b,c,d are deployed together to provide a comprehensive loss concealment in some complex decoders, while method a is relatively independent and may be only applied in some simple decoders. Moreover, frame froze method repairs video based on frames while the other methods repair video based on fine-grained elements, such as macroblock or bit-block. These will cause the measurement metrics of frame froze and the other methods slightly different. Thus, In this document, we differentiate between frame freeze and the other 3 concealment mechanisms described.
"

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

[Rachel]: It means that the MIFP = sum of the impaired proportion of each video frame / the number of frames. And the impaired proportion of each video frame = ( number of missing macroblocks from this video frame << 8 ) / the total macroblock number of the video frame. Does it solve your confusion? If it does, I'll add it to the definition.

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

[Rachel]: Here V is Video Loss Concealment Method Type, which is defined above (the third field). I'll us the full name to replace the abbreviation.

> 6. Same comment as above for definition of FFSC

[Rachel]: same as above.

> 
> 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