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

["Huangyihong (Rachel)" <[e-mail]>]

HI Vinayak,

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

BR,
Rachel


> -----Original Message-----
> From: Qin Wu
> Sent: Wednesday, September 09, 2015 9:11 AM
> To: Huangyihong (Rachel); [e-mail]; [e-mail]
> Cc: Romascanu, Dan (Dan); MORTON, ALFRED C (AL)
> Subject: RE: [pm-dir] request for an RFC 6390 review of
> https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-01.txt
> 
> FYI.
> -----邮件原件-----
> 发件人: 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.

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

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

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