Subject: [xrblock] Comments on draft-bi-xrblock-rtcp-xr-psi-dep-decodability-02

From: Alan Clark <[email-masked]>
Date: Thu, 07 Nov 2013 08:18:07 -0800

Within an MPEG transport stream the Program Specific Information is 
carried in a series of tables. The Program Association Table - PAT 
(PID=0) provides a list of the programs that are in the transport 
stream, the Conditional Access Table - CAT (PID=1) provides DRM 
information for scrambled channels.

The PAT contains a list of program numbers - and for each program number 
there is a Program Map Table (PMT) that contains a list of the PIDs 
containing the audio and video streams.

This is collectively Program Specific Information or PSI.  This 
comprises one PAT, potentially one CAT and then one PMT per program. 
Technically "Program Specific Information" is information about a 
program - it just happens to be contained in a set of tables.

The draft is titled "RTP Control Protocol (RTCP) Extended Report (XR) 
Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) 
dependent Decodability Statistics Metrics reporting".

(i) I suggest removing the word "dependent" from the title as the 
metrics are not specific to a program but relates only to the ability to 
decode program specific information.

(ii) Given (i) - remove the PID metric from the block. You could 
technically report the Program Number or PID associated with an errored 
PMT or a mismatch however that does not seem to be the intent for this 
draft.

(iii) TR101290 defines a priority 1 metric for PMT Error 2 - a counter 
for this should be added to the block

Otherwise looks ok

Alan

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 7 Nov 2013 17:26:07 +0000

Hi Alan,

Thanks for the comments. Please see inline.

Best regards,
Rachel

发件人: [email-masked] [mailto:[email-masked]] 代表 Alan Clark
发送时间: 2013年11月8日 0:18
收件人: [email-masked]
主题: [xrblock] Comments on draft-bi-xrblock-rtcp-xr-psi-dep-decodability-02

Within an MPEG transport stream the Program Specific Information is carried in a series of tables. The Program Association Table - PAT (PID=0) provides a list of the programs that are in the transport stream, the Conditional Access Table - CAT (PID=1) provides DRM information for scrambled channels.

The PAT contains a list of program numbers - and for each program number there is a Program Map Table (PMT) that contains a list of the PIDs containing the audio and video streams.

This is collectively Program Specific Information or PSI.  This comprises one PAT, potentially one CAT and then one PMT per program. Technically "Program Specific Information" is information about a program - it just happens to be contained in a set of tables.

The draft is titled "RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) dependent Decodability Statistics Metrics reporting".

(i) I suggest removing the word "dependent" from the title as the metrics are not specific to a program but relates only to the ability to decode program specific information.

(ii) Given (i) - remove the PID metric from the block. You could technically report the Program Number or PID associated with an errored PMT or a mismatch however that does not seem to be the intent for this draft.

(iii) TR101290 defines a priority 1 metric for PMT Error 2 - a counter for this should be added to the block
[Rachel]: Yes. But there’s “NOTE 2” pointing to PMT Error 2 in the TR101290. It says “Recommended for future implementations as a replacement of 1.5; this excludes specificly network_PIDs.” Can we understand that PMT Error and PMT Error 2 will not be used at the same time? If so, we only have to define on metric for both PMT Error and PMT Error 2. Right?

Otherwise looks ok

Alan

---

From: Qin Wu <[email-masked]>
Date: Thu, 7 Nov 2013 17:39:22 +0000

Alan:
Thanks for your clarification on PSI. Reply inline below.
发件人: [email-masked] [mailto:[email-masked]] 代表 Alan Clark
发送时间: 2013年11月8日 0:18
收件人: [email-masked]
主题: [xrblock] Comments on draft-bi-xrblock-rtcp-xr-psi-dep-decodability-02

[Qin]: Make sense to remove that word.

[Qin]: Just to clarify, we misunderstand your comment raised in Berlin meeting. We thought we should add PID to support reporting information per program. Obviously, we are wrong given the suggestion you give in (i).

(iii) TR101290 defines a priority 1 metric for PMT Error 2 - a counter for this should be added to the block
[Qin]: How much PMT_Error2 is different from PMT_Error. I see few difference by reading TR101.290. I also see in some demonstrated implementation, PMT_Error 2 parameter is omitted.
However if you insist, I am okay to add it into this draft.

Otherwise looks ok

Alan

---

From: Qin Wu <[email-masked]>
Date: Thu, 7 Nov 2013 18:04:13 +0000

[Qin]: Reporting PMT_Error and PMT_Error2 in the same Block allows you support various implementations which support either PMT_Error and PMT_Error2 and avoid defining two block types to carry PMT_Error and PMT_Error2 respectively.
So when only one of two is supported,  you can report one and leave the other setting to zero.

---

From: Alan Clark <[email-masked]>
Date: Thu, 07 Nov 2013 10:34:34 -0800

I'd support including both however setting to zero could be confused as
a count of zero. Could you use 0xFFFF as a not available indicator?

Alan

On 11/7/13, 10:04 AM, Qin Wu wrote:
> [Rachel]: Yes. But there’s “NOTE 2” pointing to PMT Error 2 in the
> TR101290. It says “Recommended for future implementations as a
> replacement of 1.5; this excludes specificly network_PIDs.” Can we
> understand that PMT Error and PMT Error 2 will not be used at the same
> time? If so, we only have to define on metric for both PMT Error and
> PMT Error 2. Right?
>
>
> [Qin]: Reporting PMT_Error and PMT_Error2 in the same Block allows you
> support various implementations which support either PMT_Error and
> PMT_Error2 and avoid defining two block types to carry PMT_Error and
> PMT_Error2 respectively.
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 7 Nov 2013 18:58:30 +0000

Agree. Your proposed change looks good to me.

发件人: Alan Clark [mailto:[email-masked]]
发送时间: 2013年11月8日 2:35
收件人: Qin Wu; Huangyihong (Rachel); [email-masked]
主题: Re: 答复: [xrblock] 答复: Comments on draft-bi-xrblock-rtcp-xr-psi-dep-decodability-02

I'd support including both however setting to zero could be confused as a count of zero. Could you use 0xFFFF as a not available indicator?

Alan

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 7 Nov 2013 20:05:37 +0000

Hi Qin and Alan,

IMHO, PMT_Error and PMT_Error2 will not be used simultaneously in the same system. Either PMT_Error or PMT_Error2. So I can’t imagine any cases that two block types will be defined to carry PMT_Error and PMT_Error2 respectively. However, if the consensus is to keep them both, I have no objection.

Best regards,
Rachel

Alan