Re: [xrblock] Review of draft-huang-xrblock-rtcp-xr-decodability-03

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

Hi Ray,

Thanks for your comments. Please see my answers inline.

Best Regards!
Rachel

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Brandenburg, R. (Ray) van
Sent: Thursday, July 05, 2012 5:35 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [xrblock] Review of draft-huang-xrblock-rtcp-xr-decodability-03

Hi all,

Below you will find my first review of draft-huang-xrblock-rtcp-xr-decodability-03.

*         Instead of using the term Transport Stream, it might be more precise to use the wording MPEG-2 Transport Stream. Similarly, when referencing MPEG2-TS, it might be better to reference MPEG-2 Part 1 (Systems), instead of ISO/IEC 13818-1:2007.
[Rachel] I think ISO/IEC 13818-1 is MPEG-2 Part 1.
*         I noticed the abstract of the draft references  'priorities' without explaining what those priorities are and where they come from (do they come from ETSI TR 101290?). Furthermore, such detailed information about which metrics are included and why might be better placed in the body of the document instead of in the abstract.
[Rachel] Yes, they're from ETSI TR 101290. And I agree with you that these description should be moved to the main body.
*         ETSI TR 101290 is referenced as a normative reference, although that document is a Technical Report (instead of a TS) and is thus by definition informational. A informative reference might be more suitable.
[Rachel] Okay.
*         The document at times (e.g. Section 1 and Section 3) seems to mix up the concepts of a container format (MPEG-2 TS) and the payload (codec) of such a TS (e.g. MPEG2 or MPEG4).
[Rachel] Okay. We can take some editorial work to fix it.
*         The draft might benefit from some more information on exactly what the various fields in the XR report mean. For example, while a 'PCR Repetition Count Error' might be well understood concept in the MPEG community, for this draft it might need some further explanation on exactly what this constitutes, or, in case this concept is defined somewhere else, a reference to that document.
[Rachel] Okay. Can be fixed.
*         Is it really necessary to have 32-bits for each metric? To me this seems extremely long and makes for an unnecessarily large XR block. For instance, I wouldn't expect 2^32 'Sync Byte Errors' in a given reporting period. Maybe the lengths of the fields could be reduced to 16-bit?
[Rachel] One RTP packet could contain at most 7 MPEG2TS packets. While a TS decodability rtcp xr report block is capable to report  65535 RTP packets ( the difference between  "begine seq" and "end seq" ). Therefore in some extreme cases, the error MPEG2TS packets could be at most 7*65535, which is much bigger than 16-bit. That's why we think 16-bit may not be sufficient in some cases.
Best regards,

Ray


This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer