Subject: [xrblock] FW: New Version Notification for draft-huang-xrblock-rtcp-xr-video-lc-00.txt

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 3 Jul 2014 09:19:18 +0000

Dear all,

I have just submitted a new draft about extending RTCP XR to include video loss concealment metrics. Your review and comments are highly appreciated.

BR,
Rachel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 03, 2014 5:17 PM
To: Huangyihong (Rachel); Huangyihong (Rachel)
Subject: New Version Notification for draft-huang-xrblock-rtcp-xr-video-lc-00.txt

A new version of I-D, draft-huang-xrblock-rtcp-xr-video-lc-00.txt
has been successfully submitted by Rachel Huang and posted to the IETF repository.

Name:		draft-huang-xrblock-rtcp-xr-video-lc
Revision:	00
Title:		RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications
Document date:	2014-07-03
Group:		Individual Submission
Pages:		10
URL:            http://www.ietf.org/internet-drafts/draft-huang-xrblock-rtcp-xr-video-lc-00.txt
Status:         https://datatracker.ietf.org/doc/draft-huang-xrblock-rtcp-xr-video-lc/
Htmlized:       http://tools.ietf.org/html/draft-huang-xrblock-rtcp-xr-video-lc-00

Abstract:
   This draft defines a new video loss concealment block type to augment
   those defined in [RFC3611] and [i.d-ietf-xrblock-rtcp-xr-loss-
   concealment] for use in a range of RTP video applications.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Alan Clark <[email-masked]>
Date: Thu, 03 Jul 2014 06:32:00 -0400

Hi Rachel

A few quick comments:

(i) I would avoid the use of the term "lossless" to mean video with no 
packet losses - "lossless" is usually used to mean that the video 
encoding and decoding process introduces no distortion or error. You 
could use "Loss Free Seconds" or be consistent with the other loss 
concealment draft and use the terms concealed/ unconcealed.

(ii) I would suggest changing

"Interactive repairs need the communication between receiver and sender. 
The receiving side using interactive repairs usually provides feedback 
message to the sending side for specific help. Retransmission is an 
effective interactive packet loss recovery technique for real-time 
applications with relaxed delay bounds. The sender resends packets when 
the sender notices the packets have been either damaged or lost. 
Protocols which provide such technique use a combination of 
acknowledgments, retransmission of missing and/or damaged packets. For 
example, RTP retransmission [4588]. Besides retransmission, there are 
two major feedback messages for asking for sender side repair FIR 
(RFC5104) or PLI (RFC4585)."

to

"Error concealment may involve feedback from the receiver to the sender. 
Retransmission may be used on connections with low delay or in 
delay-insensitive applications; the receiver detects missing packets or 
missing content and sends retransmission requests to the sender, 
typically using RTCP messages (RFC 4585, RFC 4588, RFC 5105 ). Other 
forms of feedback include control of the rate of forward error 
correction (FEC) codes and encoder parameters."

(iii) I would tend to use the term Retransmission rather than 
Interactive Repair for Video Loss Concealment Method as other forms of 
interactive repair would overlap with other terms (e.g. dynamic control 
of FEC rate would be an Error Resilient method).

(iv) Some of the language in the draft was reused word-for-word from 
other documents (e.g. Section 3 incorporates wording from my email to 
the XRBLOCK on 10/10/12) - you should attribute this appropriately.

Regards

Alan

On 7/3/14, 5:19 AM, Huangyihong (Rachel) wrote:
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock
>

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 4 Jul 2014 06:42:36 +0000

Hi Alan,

Thanks for your comments. Please see inline.

BR,
Rachel

> From: Alan Clark [mailto:[email-masked]]
> Sent: Thursday, July 03, 2014 6:32 PM
> To: Huangyihong (Rachel); [email-masked]
> Subject: Re: [xrblock] FW: New Version Notification for
> draft-huang-xrblock-rtcp-xr-video-lc-00.txt
> 
> Hi Rachel
> 
> A few quick comments:
> 
> (i) I would avoid the use of the term "lossless" to mean video with no packet
> losses - "lossless" is usually used to mean that the video encoding and decoding
> process introduces no distortion or error. You could use "Loss Free Seconds" or
> be consistent with the other loss concealment draft and use the terms
> concealed/ unconcealed.

[Rachel]: Thanks for the suggestion. I'm not using unconcealed is because I think it may contain video with packet losses but have not be concealed. "Loss Free Seconds" could be a good choice.
> The receiving side using interactive repairs usually provides feedback message
> to the sending side for specific help. Retransmission is an effective interactive
> packet loss recovery technique for real-time applications with relaxed delay
> bounds. The sender resends packets when the sender notices the packets have
> been either damaged or lost.
> Protocols which provide such technique use a combination of acknowledgments,
> retransmission of missing and/or damaged packets. For example, RTP
> retransmission [4588]. Besides retransmission, there are two major feedback
> messages for asking for sender side repair FIR
> delay-insensitive applications; the receiver detects missing packets or missing
> content and sends retransmission requests to the sender, typically using RTCP
> messages (RFC 4585, RFC 4588, RFC 5105 ). Other forms of feedback include
> control of the rate of forward error correction (FEC) codes and encoder
> parameters."

[Rachel]: Good suggestion. Thanks.

> 
> (iii) I would tend to use the term Retransmission rather than Interactive Repair
> for Video Loss Concealment Method as other forms of interactive repair would
> overlap with other terms (e.g. dynamic control of FEC rate would be an Error
> Resilient method).

[Rachel]: Okay, I agree. I'll change it in the next version.
> 
> (iv) Some of the language in the draft was reused word-for-word from other
> documents (e.g. Section 3 incorporates wording from my email to the XRBLOCK
> on 10/10/12) - you should attribute this appropriately.

[Rachel]: Right. Really sorry about that - copying the words without any reference or even asking. As you're the proposer, would you like to be the co-author of this draft?

> > I have just submitted a new draft about extending RTCP XR to include video
> loss concealment metrics. Your review and comments are highly appreciated.
> >
> > BR,
> > Rachel
> >
> > Subject: New Version Notification for
> > draft-huang-xrblock-rtcp-xr-video-lc-00.txt
> >
> >
> > URL:
> http://www.ietf.org/internet-drafts/draft-huang-xrblock-rtcp-xr-video-lc-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-huang-xrblock-rtcp-xr-video-lc/
> > Htmlized:
> http://tools.ietf.org/html/draft-huang-xrblock-rtcp-xr-video-lc-00
> >
> >
> > Abstract:
> > Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >