From: "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
To: "draft-huang-xrblock-rtcp-xr-decodability@tools.ietf.org"
 <draft-huang-xrblock-rtcp-xr-decodability@tools.ietf.org>
Thread-Topic: Review of draft-huang-xrblock-rtcp-xr-decodability-03
Thread-Index: Ac1ajqE1QyW9MFRJTTKg6tDL+or6FQ==
Date: Thu, 5 Jul 2012 09:34:39 +0000
Message-ID: <FCC100FC8D6B034CB88CD8173B2DA1581C6467A1@EXC-MBX03.tsn.tno.nl>
Accept-Language: en-US, nl-NL
Content-Language: en-US
Content-Type: multipart/alternative;
 boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581C6467A1EXCMBX03tsntnon_"
MIME-Version: 1.0
Cc: "xrblock@ietf.org" <xrblock@ietf.org>
Subject: [xrblock] Review of draft-huang-xrblock-rtcp-xr-decodability-03
Precedence: list

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C6467A1EXCMBX03tsntnon_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Hi all,

Below you will find my first review of draft-huang-xrblock-rtcp-xr-decodabi=
lity-03.

-       Instead of using the term Transport Stream, it might be more precis=
e to use the wording MPEG-2 Transport Stream. Similarly, when referencing M=
PEG2-TS, it might be better to reference MPEG-2 Part 1 (Systems), instead o=
f ISO/IEC 13818-1:2007.
-       I noticed the abstract of the draft references  'priorities' withou=
t explaining what those priorities are and where they come from (do they co=
me from ETSI TR 101290?). Furthermore, such detailed information about whic=
h metrics are included and why might be better placed in the body of the do=
cument instead of in the abstract.
-       ETSI TR 101290 is referenced as a normative reference, although tha=
t document is a Technical Report (instead of a TS) and is thus by definitio=
n informational. A informative reference might be more suitable.
-       The document at times (e.g. Section 1 and Section 3) seems to mix u=
p 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 Repetit=
ion Count Error' might be well understood concept in the MPEG community, fo=
r this draft it might need some further explanation on exactly what this co=
nstitutes, 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 ins=
tance, I wouldn't expect 2^32 'Sync Byte Errors' in a given reporting perio=
d. 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.tn=
o.nl/emaildisclaimer

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C6467A1EXCMBX03tsntnon_
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii">
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">
<div>Hi all,</div>
<div>&nbsp;</div>
<div>Below you will find my first review of draft-huang-xrblock-rtcp-xr-dec=
odability-03.</div>
<div>&nbsp;</div>
<ul style=3D"margin:0;padding-left:36pt;">
<li>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 IS=
O/IEC 13818-1:2007.</li><li>I noticed the abstract of the draft references&=
nbsp; &#8216;priorities&#8217; 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.</l=
i><li>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.</li><li>The =
document at times (e.g. Section 1 and Section 3) seems to mix up the concep=
ts of a container format (MPEG-2 TS) and the payload (codec) of such a TS (=
e.g. MPEG2 or MPEG4). </li><li>The draft might benefit from some more infor=
mation on exactly what the various fields in the XR report mean. For exampl=
e, while a &#8216;PCR Repetition Count Error&#8217; might be well understoo=
d 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 d=
efined somewhere else, a reference to that document.</li><li>Is it really n=
ecessary to have 32-bits for each metric? To me this seems extremely long a=
nd makes for an unnecessarily large XR block. For instance, I wouldn&#8217;=
t expect 2^32 &#8216;Sync Byte Errors&#8217; in a given reporting period. M=
aybe the lengths of the fields could
be reduced to 16-bit?</li></ul>
<div>&nbsp;</div>
<div>Best regards,</div>
<div>&nbsp;</div>
<div>Ray</div>
<div>&nbsp;</div>
</span></font>
<p>This e-mail and its contents are subject to the DISCLAIMER at http://www=
.tno.nl/emaildisclaimer</p></body>
</html>

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C6467A1EXCMBX03tsntnon_--