One document matched: draft-wu-avt-rtcp-xr-quality-monitoring-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2250 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2250.xml'>
<!ENTITY rfc3611 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml'>
<!ENTITY rfc3357 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3357.xml'>
<!ENTITY rfc3550 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'>
<!ENTITY rfc4566 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml'>
<!ENTITY rfc5216 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5216.xml'>
<!ENTITY rfc5234 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml'>
<!ENTITY rfc5296 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml'>
<!ENTITY rfc5247 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml'>
<!ENTITY I-D.ietf-avt-rapid-rtp-sync PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-rapid-rtp-sync.xml">
<!ENTITY I-D.ietf-pmol-metrics-framework PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pmol-metrics-framework.xml">
<!ENTITY I-D.hunt-avt-monarch PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hunt-avt-monarch.xml">
<!ENTITY I-D.ietf-avt-rtp-svc PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-rtp-svc.xml">
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc category="std" docName="draft-wu-avt-rtcp-xr-quality-monitoring-01" ipr="trust200902">
<front>
<title abbrev="RTCP XR Video Quality Report Blocks">RTP Control Protocol Extended Reports (RTCP XR) Report Blocks for Real-time Video Quality Monitoring</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization>Network Zen</organization>
<address>
<postal>
<street>77/440 Soi Phoomjit, Rama IV Road</street>
<street>Phra Khanong, Khlong Toie</street>
<city>Bangkok</city>
<code>10110</code>
<country>Thailand</country>
</postal>
<phone>+66 (0) 87 502 4274</phone>
<email>gwz@net-zen.net</email>
</address>
</author>
<date year="2010" />
<abstract>
<t>
This document defines a set of RTP Control Protocol Extended Reports (RTCP XR) Report Blocks and associated SDP parameters allowing the
report of video quality metrics, primarily for video applications of RTP.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Along with the wide deployment of broadband access and the development of
new IPTV services (e.g., broadcast video, video on demand),
there is increasing interest in monitoring and managing networks and
applications that deliver real-time applications over IP, to ensure that all
end users obtain acceptable video/audio quality. The main drives come
from operators, since offering performance monitoring capability can
help diagnose network impairments, facilitate in root cause
analysis and aid in verifying compliance with service level agreements (SLAs) between
Internet Service Providers (ISPs) and content providers.
<vspace blankLines="1"/>
The factors that affect real-time application quality can be
split into two categories. The first category consists of network-dependent
factors such as packet loss, delay and jitter (which also
translates into losses in the playback buffer). The factors in the
second category are application-specific factors that affect video
quality and its sensitivity to network errors. These factors can be but
not limited to video codec and loss recovery technique, coding bit rate,
packetization scheme, and content characteristics.
<vspace blankLines="1"/>
Compared with application-specific factors, the network-dependent
factors sometimes are not sufficient to measure video quality, since the
ability to analyze the video in the application layer provides
quantifiable measurements for subscriber Quality of Experience (QoE) that may not be captured in
the transmission layers or from the RTP layer down. In a typical
scenario, monitoring of the transmission layers can produce statistics suggesting
that quality is not an issue, such as the fact that network jitter is
not excessive.
However, problems may occur in the service layers leading
to poor subscriber QoE. Therefore monitoring using only network-level
measurements may be insufficient when application layer video quality is
required.
<vspace blankLines="1"/>
In order to provide accurate measures of video quality for operators
when transporting video across a network, conveying video quality metrics in RTCP XR packets
<xref target="RFC3611"/>
has the following three benefits:
<list>
<t>
<list style="symbols">
<t>
Tuning the video encoder algorithm to satisfy video quality requirements
</t>
<t>
Determining which system techniques to use in a given situation
and when to switch from one technique to another as system
parameters change
</t>
<t>
Verifying the continued correct operation of an existing system
</t>
</list>
</t>
</list>
<vspace blankLines="1"/>
<xref target="RFC3611">RFC 3611</xref> defines seven report block
formats for network management and quality monitoring.
However, there are no block types specifically designed for conveying video quality
metrics. This document focuses on specifying new report block types used
to convey video-specific quality metrics.
<vspace blankLines="1"/>
The report block types defined in this document fall into two
categories. The first category consists of synchronization information
on received RTP packets. The report blocks in the second category convey
metrics relating to packet receipts defined in <xref target="RFC3611">RFC 3611</xref>
that are summary in nature but include data that is more
detailed, or of a different type, than that conveyed in existing RTCP
packets.
<vspace blankLines="1"/>
Six report block formats are defined by this document. Of
these, two are synchronization information blocks:
<list>
<t>
<list style="symbols">
<t>RTP Flows Synchronization Delay Report Block</t>
<t>Audio-Video Synchronization Report Block</t>
</list>
</t>
</list>
<vspace blankLines="1"/>
The other four are summary metrics blocks:
<list>
<t>
<list style="symbols">
<t>Statistics Summary Report Block</t>
<t>TR 101 290 Decodability Metrics Block <xref target="ETSI"/></t>
<t>Video Stream Metrics Report Block</t>
<t>Perceptual Quality Metrics Block</t>
</list>
</t>
</list>
</t>
</section>
<section title="Terminology">
<section title="Standards Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="Acronyms">
<t>
<list style="hanging">
<t hangText="SSRC">
<vspace blankLines="0"/>
<xref target="RFC3550">Synchronization Source</xref>
<vspace blankLines="1"/>
</t>
<t hangText="TS">
<vspace blankLines="0"/>
<xref target="ISO-IEC.13818-1.2007">Transport Stream</xref>
</t>
</list>
</t>
</section>
</section>
<section title="Applicability">
<t>
All the report blocks defined in this document could be used by
dedicated network monitoring applications. As specified in
<xref target="RFC3611">RFC 3611</xref>, for such an application it might be
appropriate to allow more than 5% of RTP data bandwidth to be used for
RTCP packets, thus allowing proportionately larger and more detailed
report blocks.
<vspace blankLines="1"/>
The Audio-Video Synchronization Report Block <xref target="AVS"/>
has been defined for video
conferencing applications. Such applications can use this report
block to monitor A/V component synchronization to ensure satisfactory
QoE.
Tighter tolerances than typically used have been recommended for such
applications.
<vspace blankLines="1"/>
The Flows Synchronization Delay Report Block has been defined
primarily for layered or multi-description video coding applications.
When joining a layered video session in such an application, a receiver may
not synchronize playout across the multimedia session until RTCP SR
packets have been received on all of the component RTP sessions. This
report block can be used to ensure synchronization between different
media layers for the same multimedia session.
<vspace blankLines="1"/>
The Stream Metrics Report Block and Statistics Summary Report Block
can be applied to any real time video application, while the TR 101 290
Decodability Metrics Report Block and Perceptual Quality Metrics Report
Block can be used in any real-time AV application
<xref target="ETSI"></xref>.
</t>
</section>
<section anchor="RFSD" title="RTP Flows Synchronization Delay Report Block">
<t>
This block reports synchronization delay between RTP sessions of the
same video stream sent using Multi-Session Transmission <xref target="I-D.ietf-avt-rtp-svc"></xref>
beyond the
information carried in the standard RTCP packet format. Information is
recorded about session bandwidth and synchronization delay.
<vspace blankLines="1"/>
The RTP Flows Synchronization Delay Report Block has the following format:
<figure><artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=TBD | Reserved | Block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Synchronization Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<list style="hanging">
<t hangText="Block type (BT): 8 bits">
<vspace blankLines="0" />
The Statistics Summary Report Block is identified by the constant <RFSD>.
<vspace blankLines="1"/>
</t>
<t hangText="Reserved: 8 bits">
<vspace blankLines="0" />
This field is reserved for future definition. In the absence of such a
definition, the bits in this field MUST be set to zero and MUST be
ignored by the receiver.
<vspace blankLines="1"/>
</t>
<t hangText="Block length: 16 bits">
<vspace blankLines="0" />
The constant 3, in accordance with the definition of this field in
Section 3 of <xref target="RFC3611">RFC 3611</xref>.
<vspace blankLines="1"/>
</t>
<t hangText="SSRC of Sender: 32 bits">
<vspace blankLines="0" />The
SSRC of the RTP data packet source being reported upon by this
report block. (<xref target="RFC3611">Section 4.1 of</xref>).
<vspace blankLines="1"/>
</t>
<t hangText="Session Bandwidth: 32 bits">
<vspace blankLines="0" />
This field indicates the maximum bandwidth
allocated to each RTP Session. The value in this field represents
the bandwidth allocation per RTP Session in kilobits per second,
with values in the range 0 <= BW < 65536.
<vspace blankLines="1"/>
</t>
<t hangText="Initial Synchronization Delay: 32 bits">
<vspace blankLines="0" />
The average delay, expressed in units of 1/65536
seconds, between the RTCP packets received on all of the components
RTP sessions and the beginning of session
<xref target="I-D.ietf-avt-rapid-rtp-sync"></xref>.
The value is calculated as follows:
<vspace blankLines="1"/>
<list>
<t>
Initial Synchronization Delay = max((the time interval
between receiving the first RTP packet with synchronization
metadata and the start of a session), (the time interval between
receiving the first RTCP packet in the RTP session with the
longest RTCP reporting interval and the start of a session)).
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="AVS" title="Audio-Video Synchronization Report Block">
<t>
This block reports the audio-video synchronization requirements
between audio and video components beyond the information carried in the
standard RTCP packet format. Information is recorded about tolerant
audio lead video time and tolerant audio lag video time.
The Audio-Video Synchronization Report Block has the following format:
<figure><artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=TBD |L| Reserved | Block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Audio Lead Video | Audio Lag Video |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<list style="hanging">
<t hangText="Block type (BT): 8 bits">
<vspace blankLines="0"/>
The Statistics Summary Report Block is identified by the constant <AVS>.
<vspace blankLines="1"/>
</t>
<t hangText="Audio Lead/Lag Video flag (L): 1 bit">
<vspace blankLines="0" />
Bit set to 1 if Audio Lead Video field contains a
report, 0 if Audio Lag Video field contains a report.
<vspace blankLines="1"/>
</t>
<t hangText="Reserved: 7 bits">
<vspace blankLines="0"/>
This field is reserved for future definition. In the absence of such a
definition, the bits in this field MUST be set to zero and MUST be
ignored by the receiver.
<vspace blankLines="1"/>
</t>
<t hangText="Block length: 16 bits">
<vspace blankLines="0"/>
The constant 2, in accordance with the definition of this field in
Section 3 of <xref target="RFC3611">RFC 3611</xref>.
<vspace blankLines="1"/>
</t>
<t hangText="SSRC of source: 32 bits">
<vspace blankLines="0" />
As defined in Section 4.1 of <xref target="RFC3611">RFC 3611</xref>.
<vspace blankLines="1"/>
</t>
<t hangText="Audio Lead Video time: 16 bits">
<vspace blankLines="0"/>
This field indicates the tolerant audio lead video
time in milliseconds <xref target="DSLF"/>. This value is
calculated based on the interarrival time between previous video RTP
packet and the next first audio RTP packet and timestamps of both
previous video RTP packet and the next first audio packet.
<vspace blankLines="1"/>
</t>
<t hangText="Audio Lag Video time: 16 bits">
<vspace blankLines="0"/>
This field indicates the tolerant audio lag video
time in milliseconds <xref target="DSLF"></xref>. This value is
calculated based on the interarrival time between previous video RTP
packet and the next first audio RTP packet and timestamps of both
previous video RTP packet and the next first audio packet.
</t>
</list>
</t>
</section>
<section anchor="VSS" title="Video Statistics Summary Report Block">
<t>
This block reports statistics beyond the information carried in the
Statistics Summary Report Block RTCP packet specified in the section 4.6
of <xref target="RFC3611">RFC 3611</xref>. Information is recorded about lost
frame packets, duplicated frame packets, lost layered component packets,
duplicated layered component packets. Such information can be useful for
network management and video quality monitoring.
<vspace blankLines="1"/>
The report block contents are dependent upon a series of flag bits
carried in the first part of the header. Not all parameters need to be
reported in each block. Flags indicate which parameters are reported and
which are not. The fields corresponding to unreported parameters MUST be
present, but are set to zero. The receiver MUST ignore any Video Statistics Summary Report
Block with a non-zero value in any field flagged as unreported.
<vspace blankLines="1"/>
The Video Statistics Summary Report Block has the following format:
<figure><artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=TBD |L|D|FT | LT |P| block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_frames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup frames |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_layered component packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup layered component_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_partial frame packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup partial frame_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<list style="hanging">
<t hangText="Block type (BT): 8 bits">
<vspace blankLines="0" />
The Video Statistics Summary Report Block is identified by the constant <VSS>.
<vspace blankLines="1"/>
</t>
<t hangText="loss report flag (L): 1 bit">
<vspace blankLines="0" />
Bit set to 1 if the lost_frame packets field, the
lost_layered_component field or the lost partial frame packets field
contains a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="duplicate report flag (D): 1 bit">
<vspace blankLines="0" />
Bit set to 1 of the dup_frame packets field, the
dup_layered_component packets field or the dup partial frame packets field
contains a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="Frame type indicator (FT): 2 bits">
<vspace blankLines="0" />
This field is used to indicate the frame type to be
reported. Bits set to 01 if the lost_frames field or dup_frames field
contain a I_frame report, 10 if the lost_frames field and dup_frames
field contain a P frame report, 11 if the lost_frames field and
dup_frames field contain a B frame report, 00 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="Layer Type indicator (LT): 3 bits">
<vspace blankLines="0" />
This field is used to indicate the layer type of
layered video to be reported. LT is set to 001 if the
loss_component_packet field and dup_component packet contain the
base layer packet in SVC <xref target="I-D.ietf-avt-rtp-svc"/>, 010 if the
loss_component packet field and dup_component packet contain
enhancement layer 1 packet in SVC, 011 if the loss_component packet
field and dup_component packet contain the enhancement layer 2
packet, 000 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="P: 1 bit">
<vspace blankLines="0"/>
Bit set to 1 if the lost_partial frame packets field or the dup_partial_frame packets field
contains a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="Block length: 16 bits">
<vspace blankLines="0"/>
The constant 8, in accordance with the definition of this field in Section 3 of
<xref target="RFC3611">RFC 3611</xref>.
<vspace blankLines="1"/>
</t>
<t hangText="SSRC of source: 32 bits ">
<vspace blankLines="0"/>
As defined in Section 4.1 of <xref target="RFC3611">RFC 3611</xref>.
<vspace blankLines="1"/>
</t>
<t hangText="begin_seq: 16 bits ">
<vspace blankLines="0"/>
As defined in Section 4.1 of <xref target="RFC3611">RFC 3611</xref>.
<vspace blankLines="1"/>
</t>
<t hangText="end_seq: 16 bits ">
<vspace blankLines="0"/>
As defined in Section 4.1 of <xref target="RFC3611">RFC 3611</xref>.
<vspace blankLines="1"/>
</t>
<t hangText="lost_frames: 32 bits">
<vspace blankLines="0"/>
Number of lost_frames in the above sequence number interval.
<vspace blankLines="1"/>
</t>
<t hangText="dup_frames: 32 bits">
<vspace blankLines="0"/>
Number of dup_frames in the above sequence number interval.
<vspace blankLines="1"/>
</t>
<t hangText="lost_layered component packets: 32 bits">
<vspace blankLines="0"/>
Number of lost_component packets in the above sequence number interval.
<vspace blankLines="1"/>
</t>
<t hangText="dup_layered component packets: 32 bits">
<vspace blankLines="0"/>
Number of dup_component packets in the above sequence number interval.
<vspace blankLines="1"/>
</t>
<t hangText="lost_partial frame packets: 32 bits">
<vspace blankLines="0"/>
Number of lost_partial frame packets in the above sequence number interval.
<vspace blankLines="1"/>
</t>
<t hangText="dup_partial frame packets: 32 bits">
<vspace blankLines="0"/>
Number of dup_partial frame packets in the above sequence number interval.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section anchor="TDM" title="TR 101 290 Decodability Metrics Report Block">
<t>
This block reports decodability metrics statistics beyond the
information carried in the standard RTCP packet format. Information is
recorded about the number of Transport Stream Synchronization Losses,
Sync byte errors, Continuity count errors, Transport errors, Program Clock Reference (PCR) errors,
PCR repetition errors, PCR discontinuity
indicator errors, and Presentation Time Stamp (PTS) errors <xref target="ETSI"/>.
Such information can be useful for network
management and video quality monitoring.
<vspace blankLines="1"/>
Note that this is only applicable to MPEG-2 RTP streams <xref target="RFC2250"/>.
and not
to any other video codec.
<vspace blankLines="1"/>
The report block contents are dependent upon a series of flag bits
carried in the first part of the header. Not all parameters need to be
reported in each block. Flags indicate which are and which are not
reported. The fields corresponding to unreported parameters MUST be
present, but are set to zero. The receiver MUST ignore any Decodability
Metrics Block with a non-zero value in any field flagged as
unreported.
<vspace blankLines="1"/>
The Decodability Metrics Block has the following format:
<figure><artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=TBD |L|B|C|T|P|S|rvd| block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of packets | Number of TSs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Stream Synchronization Losses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sync byte errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Continuity count errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCR errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCR repetition errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCR discontinuity indicator errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PTS errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<list style="hanging">
<t hangText="block type (BT): 8 bits">
<vspace blankLines="0"/>
A TR 101 290 decodability metrics report block is identified by the constant <TDM>.
<vspace blankLines="1"/>
</t>
<t hangText="Transport Stream Synchronization Loss flag (L): 1 bit">
<vspace blankLines="0"/>
Bit set to 1 if the Transport Stream Synchronization Loss field contains a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="Sync byte error flag (B): 1 bit">
<vspace blankLines="0" />
Bit set to 1 if the Sync byte error field contains a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="Continuity count error flag (C): 1 bit">
<vspace blankLines="0"/>
Bit set to 1 if the Continuity count error field contains a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="Transport error flag (T): 1 bit ">
<vspace blankLines="0"/>
Bit set to 1 if the Transport error field contains a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="PCR related error flag (P): 1 bit">
<vspace blankLines="0"/>
Bit set to 1 if the PCR error field, PCR repetition error field and PCR discontinuity indicator
error fields contain a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="PTS error flag (S): 1 bit ">
<vspace blankLines="0"/>
Bit set to 1 if the PTS error field contains a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="rvd: 2 bits">
<vspace blankLines="0"/>
This field is
reserved for future definition. In the absence of such a definition,
the bits in this field MUST be set to zero and MUST be ignored by
the receiver.
<vspace blankLines="1"/>
</t>
<t hangText="block length: 16 bits">
<vspace blankLines="0"/>
The constant 10, in accordance with the definition of this field in Section 3 of
<xref target="RFC3611">RFC 3611</xref>.
<vspace blankLines="1"/>
</t>
<t hangText="SSRC of source: 32 bits">
<vspace blankLines="0"/>
As defined in Section 4.1 of <xref target="RFC3611"></xref>.
<vspace blankLines="1"/>
</t>
<t hangText="begin_seq: 16 bits">
<vspace blankLines="0"/>
As defined in Section 4.1 of <xref target="RFC3611"></xref>.
<vspace blankLines="1"/>
</t>
<t hangText="end_seq: 16 bits">
<vspace blankLines="0"/>
As defined in Section 4.1 of <xref target="RFC3611"></xref>.
<vspace blankLines="1"/>
</t>
<t hangText="Number of Packets: 16 bits">
<vspace blankLines="0"/>
Number of RTP packets in the above sequence number interval.
<vspace blankLines="1"/>
</t>
<t hangText="Number of TSs: 16 bits">
<vspace blankLines="0"/>
Number of Transport Streams in the above sequence number interval.
<vspace blankLines="1"/>
</t>
<t hangText="Transport Stream Synchronization Losses: 32 bits">
<vspace blankLines="0"/>
Number of Transport Stream Synchronization Losses
in the above sequence number interval.
<vspace blankLines="1"/>
</t>
<t hangText="Sync byte errors: 32 bits">
<vspace blankLines="0"/>
Number of Transport sync byte errors in the above sequence number interval.
</t>
<t hangText="Continuity count error: 32 bits">
<vspace blankLines="0"/>
Number of Transport Continuity count errors in the above sequence number interval.
<vspace blankLines="1"/>
</t>
<t hangText="Transport errors: 32 bits">
<vspace blankLines="0" />
Number of Transport errors in the above sequence
number interval.
<vspace blankLines="1"/>
</t>
<t hangText="PCR errors: 32 bits ">
<vspace blankLines="0"/>
Number of PCR errors in the above
sequence number interval.
<vspace blankLines="1"/>
</t>
<t hangText="PCR repetition errors: 32 bits">
<vspace blankLines="0"/>
Number of Transport PCR repetition errors in the
above sequence number interval.
<vspace blankLines="1"/>
</t>
<t hangText="PCR discontinuity indicator errors: 32 bits">
<vspace blankLines="0"/>
Number of PCR discontinuity indicator errors in the
above sequence number interval.
<vspace blankLines="1"/>
</t>
<t hangText="PTS errors: 32 bits">
<vspace blankLines="0"/>
Number of PTS errors in the above sequence number interval.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section anchor="VSM" title="Video Stream Metrics Report Block">
<t>
The Video Stream Metrics Report Block provides metrics for monitoring
the quality of video stream. This metrics includes Loss and discard
metrics, Burst metrics, Delay metrics for I-Frame packets, B-Frame
packets and P-Frame packets, Configuration parameter metrics. The block
reports separately on packets lost on the IP channel, and those that
have been received but then discarded by the receiving jitter buffer. It
also reports on the combined effect of losses and discards, as both have
equal effect on video quality.
<vspace blankLines="1"/>
In order to properly assess the quality of a video stream, it is
desirable to consider the degree of burstiness of packet loss
<xref target="RFC3357">RFC 3357</xref>.
Following the one-way loss pattern sample metrics
discussed in <xref target="RFC3357"></xref>,
a measure of the spacing
between consecutive network packet loss or error events, is a ”loss
distance”. The loss distance metric captures the spacing between the
loss periods. The duration of a loss or error event (e.g. and how many
packets are lost in that duration) is a “loss period”, the loss period
metric captures the frequency and length (burstiness) of loss once it
starts. Delay reports include the transit delay between RTP end points
and the end system processing delays, both of which contribute to the
user perceived delay.
<vspace blankLines="1"/>
Implementations MUST provide values for all the fields defined here.
For certain metrics, if the value is undefined or unknown, then the
specified default or unknown field value MUST be provided.
<vspace blankLines="1"/>
The block is encoded as six 32-bit words:
<figure><artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=TBD |FT | reserved | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss rate | Discard rate | Loss Period |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Distance | Max Loss Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Round trip delay | End system delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Gmin | RX config | JB nominal |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JB maximum | JB abs max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<list style="hanging">
<t hangText="block type (BT): 8 bits">
<vspace blankLines="0"/>
A Video Stream Metrics Report Block is identified by the constant <VSM>.
<vspace blankLines="1"/>
</t>
<t hangText="Frame type indicator (FT): 2 bits">
<vspace blankLines="0"/>
This field is used to indicate the frame type to be
reported. Bits set to 01 if the Loss rate field and discard rate
field contain a I_frame report, 10 if the Loss rate field and discard
rate field contain a P frame report, 11 if the Loss rate field and
discard rate field contain a B frame report, 00 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="reserved: 6 bits">
<vspace blankLines="0"/>
This field is reserved for future definition. In the absence of such a
definition, the bits in this field MUST be set to zero and MUST be
ignored by the receiver.
<vspace blankLines="1"/>
</t>
<t hangText="block length: 16 bits">
<vspace blankLines="0"/>
The constant 8,
in accordance with the definition of this field in Section 3 of
<xref target="RFC3611">RFC 3611</xref>.
<vspace blankLines="1"/>
</t>
<t hangText="SSRC of source: 32 bits">
<vspace blankLines="0"/>
The SSRC of the RTP data packet source being reported upon by this
report block.
in accordance with the definition of this field in Section 3 of
<xref target="RFC3611">RFC 3611</xref>.
</t>
</list>
The remaining fields are described in the following four sections:
Packet Loss and Discard Metrics, Delay Metrics, Configuration Metrics,
and Jitter Buffer Parameters.
</t>
<section title="Packet Loss and Discard Metrics">
<t>
It is very useful to distinguish between packets lost by the
network and those discarded due to jitter. Both have equal effect on
the quality of the video stream, however, having separate counts helps
identify the source of quality degradation. These fields MUST be
populated, and MUST be set to zero if no packets have been
received.
<vspace blankLines="1"/>
<list style="hanging">
<t hangText="Loss rate for I-Frame packets: 8 bits">
<vspace blankLines="0"/>
The fraction of RTP data packets from the source
lost since the beginning of reception, expressed as a fixed point
number with the binary point at the left edge of the field. This
value is calculated by dividing the total number of I frame
packets lost (after the effects of applying any error protection
such as FEC) by the total number of packets expected, multiplying
the result of the division by 256, limiting the maximum value to
255 (to avoid overflow), and taking the integer part. The numbers
of duplicated packets and discarded packets do not enter into this
calculation. Since receivers cannot be required to maintain
unlimited buffers, a receiver MAY categorize late-arriving packets
as lost. The degree of lateness that triggers a loss SHOULD be
significantly greater than that which triggers a discard.
<vspace blankLines="1"/>
</t>
<t hangText="Discard rate for I-Frame packets: 8 bits">
<vspace blankLines="0"/>
The fraction of RTP data packets from the source
that have been discarded since the beginning of reception, due to
late or early arrival, under-run or overflow at the receiving
jitter buffer. This value is expressed as a fixed point number
with the binary point at the left edge of the field. It is
calculated by dividing the total number of I-Frame packets
discarded (excluding duplicate packet discards) by the total number
of packets expected, multiplying the result of the division by
256, limiting the maximum value to 255 (to avoid overflow), and
taking the integer part.
<vspace blankLines="1"/>
</t>
<t hangText="Loss rate for P-Frame packets: 8 bits">
<vspace blankLines="0"/>
The loss rate for P-Frame packets is similar to
the loss rate for I-Frame packets. The value is calculated by
dividing the total number of P frame packets lost (after the
effects of applying any error protection such as FEC) by the total
number of packets expected, multiplying the result of the division
by 256.
<vspace blankLines="1"/>
</t>
<t hangText="Discard rate for P-Frame packets: 8 bits">
<vspace blankLines="0"/>
The discard rate for P-Frame packets is similar
to the discard rate for I-Frame packets. The value is calculated
by dividing the total number of P-Frame packets discarded (excluding
duplicate packet discards) by the total number of packets
expected, multiplying the result of the division by 256.
<vspace blankLines="1"/>
</t>
<t hangText="Loss rate for B-Frame packets: 8 bits">
<vspace blankLines="0"/>
The loss rate for B-Frame packets is similar to
the loss rate for P-Frame packets. The value is calculated by
dividing the total number of B frame packets lost (after the
effects of applying any error protection such as FEC) by the total
number of packets expected, multiplying the result of the division
by 256.
<vspace blankLines="1"/>
</t>
<t hangText="Discard rate for P-Frame packets: 8 bits">
<vspace blankLines="0"/>
The discard rate for B-Frame packets is similar
to the discard rate for P-Frame packets. The value is calculated
by dividing the total number of B-Frame packet discarded (excluding
duplicate packet discards) by the total number of packets
expected, multiplying the result of the division by 256.
</t>
</list>
</t>
</section>
<section title="Burst Metrics">
<t>
<list style="hanging">
<t hangText="Loss Distance: 16 bits">
<vspace blankLines="0"/>
The mean duration, expressed in milliseconds, of the loss intervals
that have occurred since the beginning of reception
<xref target="DSLF"></xref>. The duration of each loss distance is
calculated based upon the frames that mark the beginning and end
of that period. It is equal to the timestamp of the end frame,
plus the duration of the end frame, minus the timestamp of the
beginning frame. If the actual values are not available, estimated
values MUST be used. If there have been no burst periods, the
burst duration value MUST be zero.
<vspace blankLines="1"/>
</t>
<t hangText="Loss Period: 16 bits">
<vspace blankLines="0"/>
The mean duration, expressed in milliseconds, of the burst loss
periods that have occurred since the beginning of reception
<xref target="DSLF"></xref>. The duration of each period is calculated
based upon the frame that marks the end of the prior burst loss
and the frame that marks the beginning of the subsequent burst
loss. It is equal to the timestamp of the subsequent burst frame,
minus the timestamp of the prior burst packet, plus the duration
of the prior burst packet. If the actual values are not available,
estimated values MUST be used. In the case of a gap that occurs at
the beginning of reception, the sum of the timestamp of the prior
burst packet and the duration of the prior burst packet are
replaced by the reception start time. In the case of a gap that
occurs at the end of reception, the timestamp of the subsequent
burst packet is replaced by the reception end time. If there have
been no gap periods, the gap duration value MUST be zero.
<vspace blankLines="1"/>
</t>
<t hangText="Max Loss Duration of a single error: 16 bits">
<vspace blankLines="0"/>
The maximum loss duration, expressed in
milliseconds, of the loss periods that have occurred since the
beginning of reception. The recommended max loss duration is
specified as less than 16 ms in <xref target="DSLF"></xref>,
which provides a balance between interleaver depth protection from
xDSL errors induced by impulse noise, delay added to other
applications and video service QoE requirements to reduce visible
impairments.
</t>
</list>
</t>
</section>
<section title="Delay Metrics">
<t>
Similar to the delay metrics for audio stream defined in the
section 4.7.3 of <xref target="RFC3611"></xref>, the delay metrics for
video stream fall into two categories: end-system delay due to RTP
payload multiplexing and round trip delay due to multiplexing RTP
frames within a UDP frame.
<vspace blankLines="1"/>
<list style="hanging">
<t hangText="Round trip delay: 16 bits">
<vspace blankLines="0"/>
As defined in Section 4.7.3 of <xref target="RFC3611"></xref>.
<vspace blankLines="1"/>
</t>
<t hangText="End system delay: 16 bits">
<vspace blankLines="0"/>
As defined in Section 4.7.3 of <xref target="RFC3611"></xref>.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Configuration Parameter Metrics">
<t>
Similar to the configuration metrics defined in the section 4.7.6
of <xref target="RFC3611"></xref>, the configuration metrics for video
stream include Gmin, receiver configuration byte, packet loss
concealment, jitter buffer adaptive, and jitter buffer rate.
<vspace blankLines="1"/>
<list style="hanging">
<t hangText="Gmin: 8 bits">
<vspace blankLines="0"/>
As defined in Section 4.7.6 of <xref target="RFC3611"/>.
<vspace blankLines="1"/>
</t>
<t hangText="Receiver configuration byte (RX config): 8 bits">
<vspace blankLines="0"/>
As defined in Section 4.7.6 of <xref target="RFC3611"/>.
<vspace blankLines="1"/>
</t>
<t hangText="Jitter buffer adaptive (JBA): 2 bits">
<vspace blankLines="0"/>
As defined in Section 4.7.6 of <xref target="RFC3611"/>.
<vspace blankLines="1"/>
</t>
<t hangText="Jitter buffer rate (JB rate): 4 bits">
<vspace blankLines="0"/>
As defined in Section 4.7.6 of <xref target="RFC3611"/>.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Jitter Buffer Parameters">
<t>
Similar to the jitter buffer parameters defined in the section
4.7.7 of <xref target="RFC3611"/>,
the Jitter Buffer Parameters for video streams
include jitter buffer nominal delay, jitter buffer maximum delay and
jitter buffer absolute maximum delay.
<vspace blankLines="1"/>
<list style="hanging">
<t hangText="Jitter buffer nominal delay (JB nominal): 16 bits">
<vspace blankLines="0"/>
As defined in Section 4.7.7 of<xref target="RFC3611"></xref>.
<vspace blankLines="1"/>
</t>
<t hangText="Jitter buffer maximum delay (JB maximum): 16 bits">
<vspace blankLines="0"/>
As defined in Section 4.7.7 of<xref target="RFC3611"></xref>.
<vspace blankLines="1"/>
</t>
<t hangText="Jitter buffer absolute maximum delay (JB abs max): 16 bits">
<vspace blankLines="0"/>
As defined in Section 4.7.7 of<xref target="RFC3611"></xref>.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
</section>
<section anchor="PQM" title="Perceptual Quality Metrics Report Block">
<t>
This block reports perceptual quality metrics beyond the
information carried in the standard RTCP packet format. Information is
recorded about Video MOS, Audio Video MOS, Video Service Transmission
Quality, Video Service Audio Quality, Video Service Multimedia Quality and
Video Service Picture Quality.
<vspace blankLines="1"/>
The report block contents are dependent upon a series of flag bits
carried in the first part of the header. Not all parameters need to be
reported in each block. Flags indicate which are and which are not
reported. The fields corresponding to unreported parameters MUST be
present, but are set to zero. The receiver MUST ignore any Perceptual Quality Metrics Block
with a non-zero value in any field flagged as unreported.
<vspace blankLines="1"/>
The Perceptual Quality Metrics Block has the following format:
<figure><artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=TBD |I|S|T|A|M|P|Rsd| block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MOS-V | MOS-AV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VSTQ | VSAQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VSMQ | VSPQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Period VSPQ | Loss Distance VSPQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<list style="hanging">
<t hangText="Block type (BT): 8 bits">
<vspace blankLines="0"/>
The Perceptual Quality Metrics Block is identified by the constant <PQM>.
<vspace blankLines="1"/>
</t>
<t hangText="Interval Metric flag (I): 1 bit ">
<vspace blankLines="0"/>
This field is used to indicate whether the Basic
Loss/Discard metrics are Interval or Cumulative metrics, that is,
whether the reported values applies to the most recent measurement
interval duration between successive metrics reports (I=1) (the
Interval Duration) or to the accumulation period characteristic of
cumulative measurements (I=0) (the Cumulative Duration).
<vspace blankLines="1"/>
</t>
<t hangText="MOS-V flag (S): 1 bit ">
<vspace blankLines="0"/>
Bit set to 1 if the MOS-V field and MOS-AV field contain a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="Video Service Transmission Quality flag (T): 1 bit ">
<vspace blankLines="0"/>
Bit set to 1 if the VSTQ field contains a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="Video Service Audio Quality flag (A): 1 bit">
<vspace blankLines="0"/>
Bit set to 1 if the VSAQ field contains a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="Video Service Multimedia Quality flag (M): 1 bit">
<vspace blankLines="0"/>
Bit set to 1 if the VSMQ field contains a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="Video Service Picture Quality flag (P): 1 bit ">
<vspace blankLines="0"/>
Bit set to 1 if the VSPQ field, Loss Period VSPQ,
Loss Distance VSPQ contains a report, 0 otherwise.
<vspace blankLines="1"/>
</t>
<t hangText="Rsd.: 2 bits ">
<vspace blankLines="0"/>
This field is reserved for future definition. In the absence of such a definition,
the bits in this field MUST be set to zero and MUST be ignored by
the receiver.
<vspace blankLines="1"/>
</t>
<t hangText="SSRC of source: 32 bits">
<vspace blankLines="0"/>
As defined in Section 4.1 of <xref target="RFC3611"></xref>.
<vspace blankLines="1"/>
</t>
<t hangText="MOS-V: 16 bits">
<vspace blankLines="0"/>
The estimated mean opinion score for video quality (MOS-V) is a video quality
metric on a scale from 1 to 5, in which 5 represents excellent and 1
represents unacceptable. This metric is defined as not including the
effects of audio impairments and can be compared to MOS scores
obtained from video quality tests. It is expressed as an integer in
the range 10 to 50, corresponding to MOS x 10. For example, a value
of 35 would correspond to an estimated MOS score of 3.5.
<vspace blankLines="1" />
A value of 127 indicates that this parameter is
unavailable. Values other than 127 and the valid range defined above
MUST NOT be sent and MUST be ignored by the receiving system.
<vspace blankLines="1"/>
</t>
<t hangText="MOS-AV: 16 bits">
<vspace blankLines="1" />
The estimated mean opinion score for Audio-Video quality (MOS-AV) is
defined as including the effects of delay and other effects that
would affect Audio-Video quality. It is expressed as an integer in
the range 10 to 50, corresponding to MOS x 10, as for MOS-AV. A
value of 127 indicates that this parameter is unavailable. Values
other than 127 and the valid range defined above MUST NOT be sent
and MUST be ignored by the receiving system.
<vspace blankLines="1"/>
</t>
<t hangText="VSTQ: 16 bits">
<vspace blankLines="0"/>
Video Service Transmission Quality (TBC)
<vspace blankLines="1"/>
</t>
<t hangText="VSAQ: 16 bits">
<vspace blankLines="0"/>
Video Service Audio Quality (TBC)
<vspace blankLines="1"/>
</t>
<t hangText="VSMQ: 16 bits">
<vspace blankLines="0"/>
Video Service Multimedia Quality (TBC)
<vspace blankLines="1"/>
</t>
<t hangText="VSPQ: 16 bits">
<vspace blankLines="0"/>
Video Service Picture Quality (TBC)
<vspace blankLines="1"/>
</t>
<t hangText="Loss Period VSPQ: 16 bits">
<vspace blankLines="0"/>
Video Service Picture Quality during Loss Period (TBC)
<vspace blankLines="1"/>
</t>
<t hangText="Loss Distance VSPQ: 16 bits">
<vspace blankLines="0" />
Video Service Picture Quality during Loss Distance (TBC)
</t>
</list>
</t>
</section>
<section title="SDP Signaling">
<t>
Six new parameters are defined for the six report blocks defined in
this document to be used with Session Description Protocol (SDP)
<xref target="RFC4566"></xref> using the Augmented Backus-Naur Form (ABNF)
<xref target="RFC5234"></xref>.
They have the following syntax within the
"rtcp-xr" attribute <xref target="RFC3611"></xref>:
<figure align="left"> <artwork>
rtcp-xr-attrib = "a=rtcp-xr:"
[xr-format *(SP xr-format)] CRLF
xr-format = RTP-flows-syn
/ audio-video-syn
/ percept-quality-metrics
/ video-stream-metric
/ video-stat-summary
/ decodability-metric
RTP-flows-syn = "RTP-flows-syn"
["=" max-size]
max-size = 1*DIGIT ; maximum block size in octets
audio-video-syn = "audio-video-syn"
["=" max-size]
max-size = 1*DIGIT ; maximum block size in octets
percept-quality-metrics = "percept-quality-metrics"
["=" max-size]
max-size = 1*DIGIT ; maximum block size in octets
video-stream-metric = "video-stream-metric"
["=" max-size]
max-size = 1*DIGIT ; maximum block size in octets
video-stat-summary = "video-stat-summary"
["=" stat-flag *("," stat-flag)]
stat-flag = "I Frame loss and duplication"
/ "P Frame loss and duplication"
/ "B Frame loss and duplication"
decodability-metric = "decodability-metric"
["=" stat-flag *("," stat-flag)]
stat-flag = "Interval Metric"
/ "MOS-V and MOS-AV"
/ "VSTQ"
/ "VSAQ"
/ "VSMQ"
/ "VSPQ"
</artwork> </figure>
Refer to Section 5.1 of <xref target="RFC3611">RFC 3611</xref> for a
detailed description and the full syntax of the "rtcp-xr" attribute.
</t>
</section>
<section title="IANA Considerations">
<t>
New report block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA allocations for RTCP XR, refer to
<xref target="RFC3611">Section 6.2 of</xref>.
<vspace blankLines="1"/>
This document assigns six new block type values in the RTCP XR Block Type
Registry:
<list>
<t>
<list style="hanging" hangIndent="12">
<t hangText="Name:">RFSD</t>
<t hangText="Long Name:">RTP Flows Synchronization Delay</t>
<t hangText="Value"><RFSD></t>
<t hangText="Reference:">
<xref target="RFSD"/>
<vspace blankLines="1"/>
</t>
<t hangText="Name:">AVS</t>
<t hangText="Long Name:">Audio-Video Synchronization</t>
<t hangText="Value"><AVS></t>
<t hangText="Reference:">
<xref target="AVS"/>
<vspace blankLines="1"/>
</t>
<t hangText="Name:">VSS</t>
<t hangText="Long Name:">Video Statistics Summary</t>
<t hangText="Value"><VSS></t>
<t hangText="Reference:">
<xref target="VSS"/>
<vspace blankLines="1"/>
</t>
<t hangText="Name:">TDM</t>
<t hangText="Long Name:">TR 101 290 Decodability Metrics</t>
<t hangText="Value"><TDM></t>
<t hangText="Reference:">
<xref target="TDM"/>
<vspace blankLines="1"/>
</t>
<t hangText="Name:">VSM</t>
<t hangText="Long Name:">Video Stream Metrics</t>
<t hangText="Value"><VSM></t>
<t hangText="Reference:">
<xref target="VSM"/>
<vspace blankLines="1"/>
</t>
<t hangText="Name:">PQM</t>
<t hangText="Long Name:">Perceptual Quality Metric</t>
<t hangText="Value"><PQM></t>
<t hangText="Reference:">
<xref target="PQM"/>
<vspace blankLines="1"/>
</t>
</list>
</t>
</list>
This document also registers six SDP <xref target="RFC4566"/>
parameters for the
"rtcp-xr" attribute in the RTCP XR SDP Parameters Registry:
<list>
<t>
<list style="symbols">
<t>"RTP-flows-syn" </t>
<t>“audio-video-syn” </t>
<t>“percept-quality-metrics” </t>
<t>“video-stream-metric” </t>
<t>“video-stat-summary” </t>
<t>“decodability-metric” </t>
</list>
</t>
</list>
<vspace blankLines="1"/>
The contact information for the registrations is:
<figure align="center"><artwork>
Qin Wu
sunseawq@huawei.com
101 Software Avenue, Yuhua District
Nanjing, JiangSu 210012 China
</artwork></figure>
</t>
</section>
<section title="Security Considerations">
<t>TBC</t>
</section>
<section title="Acknowledgements">
<t>
The authors would like to thank Youqing Yang, Wenxiao Yu and Yinliang Hu
for their valuable comments and suggestions on this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&I-D.ietf-avt-rapid-rtp-sync;
&I-D.ietf-avt-rtp-svc;
&rfc2250;
&rfc3611;
&rfc2119;
&rfc4566;
&rfc5234;
&rfc3550;
<reference anchor="ETSI">
<front>
<title>Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems</title>
<author>
<organization>ETSI</organization>
</author>
<date year="2001" />
</front>
<seriesInfo name="Technical Report" value="TR 101 290"/>
</reference>
<reference anchor="ISO-IEC.13818-1.2007">
<front>
<title>Information technology - Generic coding of moving pictures and associated audio information: Systems</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date month="October" year="2007" />
</front>
<seriesInfo name="ISO" value="International Standard 13818-1" />
</reference>
</references>
<references title="Informative References">
&rfc3357;
<reference anchor="DSLF">
<front>
<title>Triple-play Services Quality of Experience (QoE) Requirements</title>
<author fullname="Tim Rahrer" initials="T.R." role="editor" surname="Rahrer">
<organization>Nortel</organization>
<address>
<postal>
<street>3500 Carling Ave.</street>
<city>Ottawa</city>
<region>Ontario</region>
<country>Canada</country>
</postal>
<phone>+1.613.763.4479</phone>
<email>tim.rahrer@nortel.com</email>
</address>
</author>
<author fullname="Riccardo Fiandra" role="editor" surname="Fiandra">
<organization>FastWeb, SpA</organization>
<address>
<email>riccardo.fiandra@fastweb.it</email>
</address>
</author>
<author fullname="Steven Wright" role="editor" surname="Wright">
<organization>BellSouth Telecommunications</organization>
<address>
<email>steven.wright@bellsouth.com</email>
</address>
</author>
<date day="13" month="December" year="2006" />
</front>
<seriesInfo name="DSL Forum Technical Report" value="TR-126"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:00:12 |