Subject: RE: [AVT] RTCP XR Report Block for IPTV Metrics...

From: "Alan Clark" <[email-masked]>
Date: Tue, 20 Mar 2007 09:09:40 -0500

Nagarjuna
 
The RTCP XR Video Metrics draft (draft-ietf-avt-rtcpxr-video-00.txt) already
addresses the issue of reporting video related performance metrics for both
unidirectional and bi-(multi-) directional streams.  This draft has already
been reviewed by a number of other standards organizations working
specifically in the IPTV area, including the ITU-T IPTV Focus Group.   My
suggestion is that if you would like to get involved in industry activities
related to IPTV performance there are quite a few other groups that more
directly address this specific application, and it would be useful to get
involved in all of these. I'd include ITU-T IPTV FG, ITU-T SG9, ITU-T SG12,
ATIS IIF, DSL Forum, DVB, VQEG, and potentially a few others.
 
With regard to the specifics of your draft:-
 
(i) A fair number of the metrics are very MPEG Transport / TR 101290
related.  While we did include some MPEG-TS related metrics in the RTCP XR
Video Metrics draft these were deliberately kept to a minimum, on the basis
that this draft is essentially RTP related.  I believe there is already a
DVB (?) protocol for reporting MPEG-TS metrics from a STB, and it may be
better to simply encapsulate that rather than invent some new protocol to do
the same thing.
 
(ii) I've already been getting comments related to the size of the XR Video
Metrics payload which is 96 bytes in length, and had to introduce a compact
format for some applications.   Your proposed report block is 
 
48 +  number of program streams * (28 + number of elementary streams * 36)
bytes long and is missing a fair amount of the data in the XR Video Metrics
block.  For the classic seven MPEG transport packets per UDP packet this
would appear to give a potential payload size of 496 bytes or more.  In a
multicast IPTV environment this means that you could be sending fairly large
numbers of 536 byte packets back to the source.
 
(iii) Main block
- Lost packets .. the RTCP XR Video Metrics distinguishes between before and
after EC loss rates, which are very helpful in understanding the
effectiveness of error correction (either FEC or some form of R-UDP)
- jitter can be due to source smoothing or network congestion - it is very
helpful to separate these (which the XR Video Metrics draft does)
- Loss periods - the issue of loss periods is addressed in the XR Video
Metrics draft
- 1st/2nd priority errors - IMHO it is more useful to know what the errors
were - however also see (i) above
- PAT gap - see (i) above
 
(iv) Program sub-block
- entirely MPEG-TS related
- in general, the IPTV STB is displaying one channel, and hence you would
expect to report on that one program channel.  Hence the heirarchic
structure of this report is a little wasted.  I admit that you could have
PIP or monitor ad insertions separately however don't think these
applications are addressed by the metrics listed.
 
(v) Elementary stream sub block
- it is very useful to report on the numbers/ proportions of I, B and P (or
at least I and B/P) frames impacted by loss.  This not only helps to provide
a better view of the impact of loss on video quality but also gives some
hints as to the cause of the loss
 
(vi) QoE metrics
Within the industry there has been good progress made in the area of video
quality metrics of various types.  It is likely that there will be at least
one NR algorithm standardized by mid-2007 with several more in early 2008.
If the premise for this draft is that since there is not an already approved
NR algorithm then by the time the draft has reached a stable state it will
have missed its objective.
Not surprisingly, I also think it very useful to report video and audio QoE
estimates.  These can be estimated from analysis of the transport stream,
codec parameters etc. however some decoders already estimate PSNR and
similar metrics (having the advantage of knowing exactly which macroblocks
needed repair).
The XR Video Metrics draft also addresses the issue of gaps in playout due
to buffer starvation, which is a reasonable metric for systems which use TCP
as a transport as well as situations of high packet loss.
 
Regards
 
Alan

 

  _____  

From: Venna, Nagarjuna [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 10:42 PM
To: [email-masked]
Subject: [AVT] RTCP XR Report Block for IPTV Metrics...

I have posted an individual draft
(http://www.ietf.org/internet-drafts/draft-venna-avt-rtcpxr-iptv-00txt
<http://www.ietf.org/internet-drafts/draft-venna-avt-rtcpxr-iptv-00.txt> )
that proposes a new RTCP-XR block for IPTV applications that use RFC 2250.

Comments and feedback are appreciated.

Thanks,
Nagarjuna 

----------------------------------------------------------------------------
--------------------------------------------------

Service Quality Matters. Test the performance and quality of your VoIP or IP
video service at:

http://www.TestYourVoIP.com <http://www.testyourvoip.com/> 

http://www.TestYourIPVideo.com <http://www.testyouripvideo.com/> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt