Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-video-01.txt

From: [email-masked]
Date: Mon, 09 Jul 2007 17:15:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTCP XR - Video Metrics Report Blocks
	Author(s)	: A. Clark, A. Pendleton
	Filename	: draft-ietf-avt-rtcpxr-video-01.txt
	Pages		: 0
	Date		: 2007-7-9
	
This document defines extensions to the RTCP XR extended report
   packet type blocks to support the monitoring of video over IP 
   for IPTV and videoconferencing endpoint reporting.
   [Note that the audio and transport metric report blocks contained
   in the -00 draft have been moved to separate drafts.]

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcpxr-video-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-avt-rtcpxr-video-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtcpxr-video-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Ali Begen \(abegen\)" <[email-masked]>
Date: Mon, 23 Jul 2007 07:22:52 -0700

Hello,

I have some questions and suggestions for the RTCP XR video draft. I am
hoping to discuss these in today's session.

Questions Regarding Existing Fields:

1) Proportion of impaired I/BP frames:
It should be made clear how the proportion of impaired frames is defined
and can be computed. 
Example: Assume that the measurement interval is one GOP duration, and
the I-frame for the current GOP is lost. 
- Is the proportion of impaired B and P frames (denoted by X) 100%?
- Does the value of X depend on the successful and on-time arrival of B
or P frames? Or, as they cannot be decoded already in case of an I-frame
loss, is X 100%?

2) Loss rate within BP frames:
Is this the absolute loss rate within BP frames or does it include the
discarded frames/slices due to missing ancestor frames? (Related to the
previous question)

3) Max GOP length:
This is computed in a way such that it is a non-decreasing function of
time. Thus, it keeps the value of the largest GOP size that has been
seen since it was reset.
- Does MGOP span the whole session or only the interval during which the
measurement is made?
Knowing the value of the largest GOP size that has been seen since the
beginning of the session might give the decoder an idea of how the
encoder is working, although an information from several hours ago won't
say much. 
- Similarly, is mean GOP length reset at some point?

4) Proportion of time below MOS threshold:
MOS can be calculated over an observation interval (which can be the
measurement interval). It is difficult to define/compute MOS over very
short intervals (e.g., per frame). Thus, it is even more difficult to
find the proportion of time below MOS threshold. How can we compute this
value?

5) PSNR fields:
What is the suggested way to "estimate" the PSNR without the reference
frames?

Possible Field Additions:

1) Proportion of total frame losses:
Some decoder hardware chips do not support reporting individual B/P
frame loss rates. For such cases, we should support a field that reports
the aggregated loss rate for whole frame types.

2) PCR discontinuity counter: (aggregate number of discontinuities seen)
Maybe useful when tracking is lost due to open loop NLL.

3) Separate fields for video playout underrun and overrun counts:
Playout interrupt count field only counts the number of interrupts due
to buffer underrun. Some hardware chips flush out the buffer when an
overrun occurs. Having a separate field for overruns may signal the
encoder/transmitter to adjust the encoding/transmission rate.

Thanks,
-Ali

--
Ali C. Begen, Ph.D.

Software Engineer
Video Content & Networking Business Unit
Cisco Systems, Inc.
San Jose, CA 95134 USA
w. +1 (408) 525-7308

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, July 09, 2007 2:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcpxr-video-01.txt 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message. 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: "Alan Clark" <[email-masked]>
Date: Mon, 23 Jul 2007 16:31:07 -0400

Hi Ali

I look forward to answering your questions this afternoon in the meeting
however:-

1) Proportion of impaired I/BP frames:
It should be made clear how the proportion of impaired frames is defined and
can be computed. 
Example: Assume that the measurement interval is one GOP duration, and the
I-frame for the current GOP is lost. 
- Is the proportion of impaired B and P frames (denoted by X) 100%?
- Does the value of X depend on the successful and on-time arrival of B or P
frames? Or, as they cannot be decoded already in case of an I-frame loss, is
X 100%?

> An interval would be at least a typical inter-RTCP gap, which may be 5-20
seconds and hence would not normally span a single GoP.  This metric does
not consider error propagation through the GoP.  The expectation is that a
high proportion of impaired I frames would lead to extensive error
propagation.

> This is the loss rate in received frames, and does not take into account
propagation.  The loss rate in I and BP frames is intended to support
network problem identification (e.g. high I frame loss rate may indicate
self induced congestion)

3) Max GOP length:
This is computed in a way such that it is a non-decreasing function of time.
Thus, it keeps the value of the largest GOP size that has been seen since it
was reset.
- Does MGOP span the whole session or only the interval during which the
measurement is made?
Knowing the value of the largest GOP size that has been seen since the
beginning of the session might give the decoder an idea of how the encoder
is working, although an information from several hours ago won't say much. 
- Similarly, is mean GOP length reset at some point?

> This would be the largest GoP seen during the measurement interval.  

4) Proportion of time below MOS threshold:
MOS can be calculated over an observation interval (which can be the
measurement interval). It is difficult to define/compute MOS over very short
intervals (e.g., per frame). Thus, it is even more difficult to find the
proportion of time below MOS threshold. How can we compute this value?

> It is possible to compute an estimated short term MOS - although
subjective tests do use typically 10-20 second samples.  

5) PSNR fields:

> I'll explain in more detail later - however to provide an example - a
decoder does know what proportion of the macroblocks in the decoded image
needed to be concealed, and does know what concealment method was used -
this does enable an approximation to PSNR to be computed.  This approach is
already used by some video decoders.

1) Proportion of total frame losses:
Some decoder hardware chips do not support reporting individual B/P frame
loss rates. For such cases, we should support a field that reports the
aggregated loss rate for whole frame types.

> Agreed

> There is a separate draft on MPEG Transport metrics which includes this
(draft-ietf-avt-rtcpxr-mpts-00.txt)

3) Separate fields for video playout underrun and overrun counts:
Playout interrupt count field only counts the number of interrupts due to
buffer underrun. Some hardware chips flush out the buffer when an overrun
occurs. Having a separate field for overruns may signal the
encoder/transmitter to adjust the encoding/transmission rate.

> I'd like to discuss this further however it seems reasonable

Regards

Alan