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

["Brandenburg, R. (Ray) van" <[e-mail]>]

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