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

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 5 Jul 2012 09:34:39 +0000

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

Best regards,

Ray

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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 10 Jul 2012 06:51:04 +0000

Hi Ray,

Thanks for your comments. Please see my answers inline.

Best Regards!
Rachel

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

Hi all,

*         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

---

From: Glen Zorn <[email-masked]>
Date: Thu, 12 Jul 2012 11:34:57 +0700

On Thu, 2012-07-05 at 09:34 +0000, Brandenburg, R. (Ray) van wrote:

>         
>       * 
>       * 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?). 

See below.

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

The ETSI classification of a document is largely irrelevant IMHO: I
believe that, in the IETF, a normative reference is one which must be
read and understood in order to read and understand the document citing
it.  ETSI TR 101290 seems to me to fit those criteria in this case.

...

---

From: Qin Wu <[email-masked]>
Date: Thu, 19 Jul 2012 13:49:13 +0800

Yes, I tend to agree to put ETSI TR 101.290 as normative reference.

Regards!
-Qin
  ----- Original Message ----- 
  From: Glen Zorn 
  To: [email-masked] 
  Sent: Thursday, July 12, 2012 12:34 PM
  Subject: Re: [xrblock] Review of draft-huang-xrblock-rtcp-xr-decodability-03

      a.. 
      b.. 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?). 

  See below.

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

  The ETSI classification of a document is largely irrelevant IMHO: I believe that, in the IETF, a normative reference is one which must be read and understood in order to read and understand the document citing it.  ETSI TR 101290 seems to me to fit those criteria in this case.

  ... 

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

  _______________________________________________
  xrblock mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/xrblock