Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi-decodability-00.txt

[Colin Perkins <[e-mail]>]

On 16 Dec 2013, at 18:10, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Metric Blocks for use with RTCP's Extended Report Framework Working Group of the IETF.
> 
> 	Title           : RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics reporting
> 	Author(s)       : Jiangang Tong
>                          Claire Bi
>                          Roni Even
>                          Qin Wu
>                          Rachel Huang
> 	Filename        : draft-ietf-xrblock-rtcp-xr-psi-decodability-00.txt
> 	Pages           : 10
> 	Date            : 2013-12-05
> 
> Abstract:
>   An MPEG2 Transport Stream (TS) is a standard container format used in
>   the transmission and storage of multimedia data.  Unicast/Multicast
>   MPEG2 TS over RTP is widely deployed in IPTV systems.  This document
>   defines an RTP Control Protocol (RTCP) Extended Report (XR) Block
>   that allows the reporting of MPEG2 TS decodability statistics metrics
>   related to transmissions of MPEG2 TS over RTP.  The metrics specified
>   in the RTCP XR Block are related to Program specific information
>   carried in MPEG TS.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-psi-decodability

It occurs to me that the issue with begin_seq and end_seq having to be within the same RTP sequence number cycle to be unambiguous is present in this draft, as well as the post-repair-loss-count draft (also in RFC 6990 and maybe other places). The various *_count field here can probably all be shortened to 16 bits without changing the utility of the report block (several use 0xFFFF as an over-range value, so this seems to be implied anyway).


-- 
Colin Perkins
http://csperkins.org/