1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Internet Engineering Task Force (IETF) R. Huang
Request for Comments: 7867 Huawei
Category: Standards Track July 2016
ISSN: 2070-1721
<span class="h1">RTP Control Protocol (RTCP) Extended Report (XR) Block</span>
<span class="h1">for Loss Concealment Metrics for Video Applications</span>
Abstract
This document defines a new RTP Control Protocol (RTCP) Extended
Report (XR) block that allows the reporting of loss concealment
metrics for video applications of RTP.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7867">http://www.rfc-editor.org/info/rfc7867</a>.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Huang Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. RTCP and RTCP XR Reports ...................................<a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Performance Metrics Framework ..............................<a href="#page-3">3</a>
<a href="#section-1.3">1.3</a>. Applicability ..............................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Video Loss Concealment Methods ..................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Video Loss Concealment Report Block .............................<a href="#page-4">4</a>
<a href="#section-5">5</a>. SDP Signaling ...................................................<a href="#page-8">8</a>
<a href="#section-5.1">5.1</a>. SDP rtcp-xr-attrib Attribute Extension .....................<a href="#page-8">8</a>
<a href="#section-5.2">5.2</a>. Offer/Answer Usage .........................................<a href="#page-9">9</a>
<a href="#section-6">6</a>. Security Considerations .........................................<a href="#page-9">9</a>
<a href="#section-7">7</a>. IANA Considerations .............................................<a href="#page-9">9</a>
<a href="#section-7.1">7.1</a>. New RTCP XR Block Type Value ...............................<a href="#page-9">9</a>
<a href="#section-7.2">7.2</a>. New RTCP XR SDP Parameter ..................................<a href="#page-9">9</a>
<a href="#section-7.3">7.3</a>. Contact Information for Registrations .....................<a href="#page-10">10</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-10">10</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-10">10</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-11">11</a>
<a href="#appendix-A">Appendix A</a>. Metrics Represented Using the Template from <a href="./rfc6390">RFC 6390</a> ..12
Acknowledgements ..................................................<a href="#page-16">16</a>
Authors' Addresses ................................................<a href="#page-16">16</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Multimedia applications often suffer from packet losses in IP
networks. In order to get a reasonable degree of quality when there
is packet loss, it is necessary to have loss concealment mechanisms
at the decoder. Video loss concealment is a range of techniques to
mask the effects of packet loss in video communications.
In some applications, reporting the information of receivers applying
video loss concealment could give monitors or senders useful
information on the Quality of Experience (QoE) of the application.
One example is no-reference video quality evaluation. Video probes
located upstream from the video endpoint or terminal may not see loss
occurring between the probe and the endpoint, and also may not be
fully aware of the specific loss concealment methods being
dynamically applied by the video endpoint. Evaluating error
concealment is important in this circumstance to estimate the
subjective impact of impairments.
This document defines one new block type for video loss concealment
to augment those defined in [<a href="./rfc3611" title=""RTP Control Protocol Extended Reports (RTCP XR)"">RFC3611</a>] and [<a href="./rfc7294" title=""RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications"">RFC7294</a>] for use in a
range of RTP video applications. The metrics defined in this
document belong to the class of transport-related terminal metrics
defined in [<a href="./rfc6792" title=""Guidelines for Use of the RTP Monitoring Framework"">RFC6792</a>].
<span class="grey">Huang Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. RTCP and RTCP XR Reports</span>
The use of RTCP for reporting is defined in [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. [<a href="./rfc3611" title=""RTP Control Protocol Extended Reports (RTCP XR)"">RFC3611</a>]
defines an extensible structure for reporting using an RTCP Extended
Report (XR). This document defines a new Extended Report block that
is used as defined in [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] and [<a href="./rfc3611" title=""RTP Control Protocol Extended Reports (RTCP XR)"">RFC3611</a>].
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Performance Metrics Framework</span>
The Performance Metrics Framework [<a href="./rfc6390" title=""Guidelines for Considering New Performance Metric Development"">RFC6390</a>] provides guidance on the
definition and specification of performance metrics. The RTP
monitoring framework [<a href="./rfc6792" title=""Guidelines for Use of the RTP Monitoring Framework"">RFC6792</a>] provides guidelines for the reporting
block format using RTCP XR. The XR block type described in this
document is in accordance with the guidelines in [<a href="./rfc6390" title=""Guidelines for Considering New Performance Metric Development"">RFC6390</a>] and
[<a href="./rfc6792" title=""Guidelines for Use of the RTP Monitoring Framework"">RFC6792</a>].
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Applicability</span>
These metrics are applicable to video applications the video
component of audio/video applications using RTP and applying packet
loss concealment mechanisms that are incorporated into the receiving
endpoint to mitigate the impact of network impairments on QoE. For
example, in an IPTV system, set-top boxes could use this RTCP XR
block to report loss and loss concealment metrics to an IPTV
management system to enable the service provider to monitor the
quality of the IPTV service being delivered to end users.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Video Loss Concealment Methods</span>
Video loss concealment mechanisms can be classified into 4 types as
follows:
a) Frame freeze
The impaired video frame is not displayed; instead, the previously
displayed frame is frozen for the duration of the loss event.
b) Interframe extrapolation
If an area of the video frame is damaged by loss, the same area
from the previous frame(s) can be used to estimate what the
missing pixels would have been. This can work well in a scene
<span class="grey">Huang Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
with no motion but can be very noticeable if there is significant
movement from one frame to another. Simple decoders can simply
reuse the pixels that were in the missing area, while more complex
decoders can try to use several frames to do a more complex
extrapolation. Another example of a sophisticated form of
interframe repair is to estimate the motion of the damaged region
based on the motion of surrounding regions, and use that to select
what part of the previous frame to use for repair. Some important
frames, such as Instantaneous Decoding Refresh (IDR) frames, may
not depend on any other frames and may be involved in a scene
change. Using the interframe extrapolation method to conceal the
loss of these frames may not obtain a satisfactory result.
c) Interpolation
A decoder uses the undamaged pixels in the video frame to estimate
what the missing block of pixels should have.
d) Error-resilient encoding
The sender encodes the message in a redundant way so that the
receiver can correct errors using the redundant information.
There are usually two kinds of error-resilient encoding: One is
that the redundant data useful for error resiliency performed at
the decoder can be embedded into the compressed image/video
bitstream. The other is encoding at the bitstream level, e.g.,
Forward Error Correction (FEC).
Usually, methods b, c, and d are deployed together to provide
comprehensive loss concealment in complex decoders, while method a is
relatively independent and may be applied in some simple decoders.
Moreover, the frame-freeze method repairs video based on frames,
while the other methods repair video based on fine-grained elements,
such as macroblocks or bitstreams; this will cause the measurement
metrics of frame-freeze and the other methods to be slightly
different. Thus, In this document, we differentiate between frame-
freeze and the other 3 loss concealment mechanisms.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Video Loss Concealment Report Block</span>
This block reports the video loss concealment metrics to complement
the audio metrics defined in [<a href="./rfc7294" title=""RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications"">RFC7294</a>]. The report block MUST be
sent in conjunction with the information from the Measurement
Information Block [<a href="./rfc6776" title=""Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block"">RFC6776</a>]. Instances of this metric block refer by
synchronization source (SSRC) to the separate auxiliary Measurement
Information Block [<a href="./rfc6776" title=""Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block"">RFC6776</a>]. The Video Loss Concealment Report Block
relies on the measurement period in the Measurement Information Block
indicating the span of the report. If the measurement period is not
<span class="grey">Huang Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
received in the same compound RTCP packet as this metric block, this
metric block MUST be discarded at the receiving side. The metrics in
this report block are based on measurements that are typically made
at the time that a video frame is decoded and rendered for playout.
The Video Loss Concealment Report Block has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=34 | I | V | RSV | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Impaired Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Concealed Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mean Frame Freeze Duration (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIFP | MCFP | FFSC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for the Video Loss Concealment Report Block
Block Type (BT): 8 bits
A Video Loss Concealment Report Block is identified by the
constant 34.
Interval Metric Flag (I): 2 bits
This field indicates whether the reported metrics are interval,
cumulative, or sampled metrics [<a href="./rfc6792" title=""Guidelines for Use of the RTP Monitoring Framework"">RFC6792</a>]:
I=10: Interval Duration - the reported value applies to the
most recent measurement interval duration between
successive metrics reports.
I=11: Cumulative Duration - the reported value applies to the
accumulation period characteristic of cumulative
measurements.
I=01: Sampled Value - this value MUST NOT be used for this
block type.
I=00: Reserved.
<span class="grey">Huang Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
Video Loss Concealment Method Type (V): 2 bits
This field is used to identify the video loss concealment method
type used at the receiver. The value is defined as follows:
V=10: Frame-freeze
V=11: Other Loss Concealment Method
V=01 and V=00: Reserved
If frame-freeze and another loss concealment method are used
together for the media stream, two report blocks (one with V=10
for frame freeze and one with V=11 for the other loss concealment
method) SHOULD be compounded together to report complete
concealment information.
RSV: 4 bits
These bits are reserved for future use. They MUST be set to zero
by senders and ignored by receivers (see <a href="./rfc6709#section-4.2">Section 4.2 of
[RFC6709]</a>).
Block Length: 16 bits
This field is in accordance with the definition in [<a href="./rfc3611" title=""RTP Control Protocol Extended Reports (RTCP XR)"">RFC3611</a>]. In
this report block, it MUST be set to 5 when V=10 and set to 4 when
V=11. The block MUST be discarded if the block length is set to a
different value.
SSRC of Source: 32 bits
As defined in <a href="./rfc3611#section-4.1">Section 4.1 of [RFC3611]</a>.
Impaired Duration: 32 bits
The total duration, expressed in units of RTP timestamp from the
sending side of the reporting block, of video impaired by
transmission loss before applying any loss concealment methods.
Two values are reserved: A value of 0xFFFFFFFE indicates out of
range (that is, a measured value exceeding 0xFFFFFFFD), and a
value of 0xFFFFFFFF indicates that the measurement is unavailable.
Concealed Duration: 32 bits
The total duration, expressed in units of RTP timestamp from the
sending side of the reporting block, of concealed damaged video
pictures on which the loss concealment method corresponding to the
Video Loss Concealment Method Type is applied.
<span class="grey">Huang Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
Two values are reserved: A value of 0xFFFFFFFE indicates out of
range (that is, a measured value exceeding 0xFFFFFFFD), and a
value of 0xFFFFFFFF indicates that the measurement is unavailable.
Mean Frame-Freeze Duration: 32 bits
Mean Frame-Freeze Duration is the mean duration, expressed in
units of RTP timestamp from the sending side of the reporting
block, of the frame-freeze events. The value of Mean Frame-Freeze
Duration is calculated by summing the total duration of all frame
freeze events and dividing by the number of events. This metric
is optional. It only exists when Video Loss Concealment Method
Type=10.
Mean Impaired Frame Proportion (MIFP): 8 bits
Mean Impaired Frame Proportion is the mean proportion of each
video frame impaired by loss before applying any loss concealment
method during the interval, expressed as a fixed-point number with
the binary point at the left edge of the field. It is calculated
by summing the impaired proportion of each video frame and
dividing by the number of frames during this period. The impaired
proportion of each video frame is obtained by dividing the number
of missing macroblocks from this video frame by the total
macroblock number of the video frame, which is equivalent to
multiplying the result of the division by 256, limiting the
maximum value to 255 (to avoid overflow), and taking the integer
part.
If a video frame is totally lost, a value of 0xFF SHOULD be used
for the frame when calculating the MIFP.
Mean Concealed Frame Proportion (MCFP): 8 bits
Mean Concealed Frame Proportion is the mean proportion of each
video frame to which loss concealment (depicted as "V" in the
definition of "Video Loss Concealment Method Type") was applied
during the interval, expressed as a fixed-point number with the
binary point at the left edge of the field. It is calculated by
summing the concealed proportion of each video frame and dividing
by the number of frames during this period. The concealed
proportion of each video frame is obtained by dividing the number
of concealed macroblocks from this video frame by the total
macroblock number of the video frame, which is equivalent to
multiplying the result of the division by 256, limiting the
maximum value to 255 (to avoid overflow), and taking the integer
part.
<span class="grey">Huang Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
When calculating the MCFP, a value of 0xFF SHOULD be used for a
lost frame that is totally concealed, and a value of 0 SHOULD be
used for the frame if there are no concealed macroblocks in it.
For Video Loss Concealment Method Type=10, each frame covered in
the period of frame freeze is considered to be totally concealed;
this means a value of 0xFF MUST be assigned.
Fraction of Frames Subject to Concealment (FFSC): 8 bits
Fraction of Frames Subject to Concealment is calculated by
dividing the number of frames to which loss concealment (using
Video Loss Concealment Method Type) was applied by the total
number of frames and expressing this value as a fixed-point number
with the binary point at the left edge of the field. It is
equivalent to multiplying the result of the division by 256,
limiting the maximum value to 255 (to avoid overflow), and taking
the integer part.
A value of 0 indicates that there were no concealed frames, and a
value of 0xFF indicates that the frames in the entire measurement
interval are all concealed.
Reserved: 8 bits
These bits are reserved for future use. They MUST be set to zero
by senders and ignored by receivers (see <a href="./rfc6709#section-4.2">Section 4.2 of
[RFC6709]</a>).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. SDP Signaling</span>
[<a id="ref-RFC3611">RFC3611</a>] defines the use of the Session Description Protocol (SDP)
for signaling the use of RTCP XR blocks.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. SDP rtcp-xr-attrib Attribute Extension</span>
This session augments the SDP attribute "rtcp-xr" defined in <a href="./rfc3611#section-5.1">Section</a>
<a href="./rfc3611#section-5.1">5.1 of [RFC3611]</a> by providing an additional value of "xr-format" to
signal the use of the report block defined in this document. The
ABNF [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] syntax is as follows.
xr-format =/ xr-vlc-block
xr-vlc-block = "vlc"
<span class="grey">Huang Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Offer/Answer Usage</span>
When SDP is used in an offer/answer context, the SDP Offer/Answer
usage defined in <a href="./rfc3611#section-5.2">Section 5.2 of [RFC3611]</a> for the unilateral
"rtcp-xr" attribute parameters applies. For detailed usage of
Offer/Answer for unilateral parameters, refer to <a href="./rfc3611#section-5.2">Section 5.2 of
[RFC3611]</a>.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
It is believed that this RTCP XR block introduces no new security
considerations beyond those described in [<a href="./rfc3611" title=""RTP Control Protocol Extended Reports (RTCP XR)"">RFC3611</a>]. This block does
not provide per-packet statistics, so the risk to confidentiality
documented in paragraph 3 of <a href="./rfc3611#section-7">Section 7 of [RFC3611]</a> does not apply.
An attacker is likely to put incorrect information in the Video Loss
Concealment reports; this will affect the estimation of the
performance of video loss concealment mechanisms and the QoE of
users. Implementers SHOULD consider the guidance in [<a href="./rfc7202" title=""Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution"">RFC7202</a>] for
using appropriate security mechanisms, i.e., where security is a
concern, the implementation SHOULD apply encryption and
authentication to the report block. For example, this can be
achieved by using the AVPF profile together with the Secure RTP
profile as defined in [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>]; an appropriate combination of the
two profiles (an "SAVPF") is specified in [<a href="./rfc5124" title=""Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)"">RFC5124</a>]. However, other
mechanisms also exist (documented in [<a href="./rfc7201" title=""Options for Securing RTP Sessions"">RFC7201</a>]) and might be more
suitable.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, please refer
to [<a href="./rfc3611" title=""RTP Control Protocol Extended Reports (RTCP XR)"">RFC3611</a>].
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. New RTCP XR Block Type Value</span>
This document assigns the block type value 34 to Video Loss
Concealment Metric Report Block in the IANA "RTP Control Protocol
Extended Reports (RTCP XR) Block Type Registry".
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. New RTCP XR SDP Parameter</span>
This document also registers a new parameter "video-loss-concealment"
in the "RTP Control Protocol Extended Reports (RTCP XR) Session
Description Protocol (SDP) Parameters Registry".
<span class="grey">Huang Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Contact Information for Registrations</span>
The contact information for the registration is:
RAI Area Directors <rai-ads@ietf.org>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3550">RFC3550</a>] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, <a href="./rfc3550">RFC 3550</a>, DOI 10.17487/RFC3550,
July 2003, <<a href="http://www.rfc-editor.org/info/rfc3550">http://www.rfc-editor.org/info/rfc3550</a>>.
[<a id="ref-RFC3611">RFC3611</a>] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)",
<a href="./rfc3611">RFC 3611</a>, DOI 10.17487/RFC3611, November 2003,
<<a href="http://www.rfc-editor.org/info/rfc3611">http://www.rfc-editor.org/info/rfc3611</a>>.
[<a id="ref-RFC3711">RFC3711</a>] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
<a href="./rfc3711">RFC 3711</a>, DOI 10.17487/RFC3711, March 2004,
<<a href="http://www.rfc-editor.org/info/rfc3711">http://www.rfc-editor.org/info/rfc3711</a>>.
[<a id="ref-RFC5124">RFC5124</a>] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", <a href="./rfc5124">RFC 5124</a>, DOI 10.17487/RFC5124, February
2008, <<a href="http://www.rfc-editor.org/info/rfc5124">http://www.rfc-editor.org/info/rfc5124</a>>.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>,
DOI 10.17487/RFC5234, January 2008,
<<a href="http://www.rfc-editor.org/info/rfc5234">http://www.rfc-editor.org/info/rfc5234</a>>.
[<a id="ref-RFC6776">RFC6776</a>] Clark, A. and Q. Wu, "Measurement Identity and Information
Reporting Using a Source Description (SDES) Item and an
RTCP Extended Report (XR) Block", <a href="./rfc6776">RFC 6776</a>,
DOI 10.17487/RFC6776, October 2012,
<<a href="http://www.rfc-editor.org/info/rfc6776">http://www.rfc-editor.org/info/rfc6776</a>>.
<span class="grey">Huang Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
[<a id="ref-RFC7294">RFC7294</a>] Clark, A., Zorn, G., Bi, C., and Q. Wu, "RTP Control
Protocol (RTCP) Extended Report (XR) Blocks for
Concealment Metrics Reporting on Audio Applications",
<a href="./rfc7294">RFC 7294</a>, DOI 10.17487/RFC7294, July 2014,
<<a href="http://www.rfc-editor.org/info/rfc7294">http://www.rfc-editor.org/info/rfc7294</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC6390">RFC6390</a>] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", <a href="https://www.rfc-editor.org/bcp/bcp170">BCP 170</a>, <a href="./rfc6390">RFC 6390</a>,
DOI 10.17487/RFC6390, October 2011,
<<a href="http://www.rfc-editor.org/info/rfc6390">http://www.rfc-editor.org/info/rfc6390</a>>.
[<a id="ref-RFC6709">RFC6709</a>] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", <a href="./rfc6709">RFC 6709</a>,
DOI 10.17487/RFC6709, September 2012,
<<a href="http://www.rfc-editor.org/info/rfc6709">http://www.rfc-editor.org/info/rfc6709</a>>.
[<a id="ref-RFC6792">RFC6792</a>] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use
of the RTP Monitoring Framework", <a href="./rfc6792">RFC 6792</a>,
DOI 10.17487/RFC6792, November 2012,
<<a href="http://www.rfc-editor.org/info/rfc6792">http://www.rfc-editor.org/info/rfc6792</a>>.
[<a id="ref-RFC7201">RFC7201</a>] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", <a href="./rfc7201">RFC 7201</a>, DOI 10.17487/RFC7201, April 2014,
<<a href="http://www.rfc-editor.org/info/rfc7201">http://www.rfc-editor.org/info/rfc7201</a>>.
[<a id="ref-RFC7202">RFC7202</a>] Perkins, C. and M. Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media
Security Solution", <a href="./rfc7202">RFC 7202</a>, DOI 10.17487/RFC7202, April
2014, <<a href="http://www.rfc-editor.org/info/rfc7202">http://www.rfc-editor.org/info/rfc7202</a>>.
<span class="grey">Huang Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Metrics Represented Using the Template from <a href="./rfc6390">RFC 6390</a></span>
a. Video Impaired Duration Metric
* Metric Name: Video Impaired Duration Metric
* Metric Description: The total duration of the video impaired by
transmission loss before applying any loss concealment methods.
* Method of Measurement or Calculation: The metric is based on
measurements that are typically made at the time that a video
frame is decoded and rendered for playout.
* Units of Measurement: This metric is expressed in units of RTP
timestamp.
* Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream.
* Measurement Timing: See paragraph 1 of <a href="#section-4">Section 4</a>.
* Use and Applications: The metric is applicable to video
applications of RTP and the video component of audio/video
applications in which packet loss concealment mechanisms are
applied to the receiving endpoint to mitigate the impact of
network impairments on QoE.
b. Video Concealed Duration Metric
* Metric Name: Video Concealed Duration Metric
* Metric Description: The total duration of concealed damaged
video pictures on which loss concealment method corresponding
to Video Loss Concealment Method Type is applied.
* Method of Measurement or Calculation: The metric is based on
measurements that are typically made at the time that a video
frame is decoded and rendered for playout.
* Units of Measurement: This metric is expressed in units of RTP
timestamp.
* Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream.
* Measurement Timing: See paragraph 1 of <a href="#section-4">Section 4</a>.
<span class="grey">Huang Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
* Use and Applications: These metrics are applicable to video
applications of RTP and the video component of audio/video
applications in which packet loss concealment mechanisms are
incorporated into the receiving endpoint to mitigate the impact
of network impairments on QoE.
c. Mean Video Frame-Freeze Duration Metric
* Metric Name: Mean Video Frame-Freeze Duration Metric
* Metric Description: The mean duration of the frame-freeze
events.
* Method of Measurement or Calculation: The metric is based on
measurements that are typically made at the time that a video
frame is decoded and rendered for playout. The metric is
calculated by summing the total duration of all frame-freeze
events and dividing by the number of events.
* Units of Measurement: This metric is expressed in units of RTP
timestamp.
* Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream.
* Measurement Timing: See paragraph 1 of <a href="#section-4">Section 4</a>.
* Use and Applications: These metrics are applicable to video
applications of RTP and the video component of audio/video
applications in which packet loss concealment mechanisms are
incorporated into the receiving endpoint to mitigate the impact
of network impairments on QoE.
d. Mean Impaired Video Frame Proportion Metric
* Metric Name: Mean Impaired Video Frame Proportion Metric
* Metric Description: Mean proportion of each video frame
impaired by loss before applying any loss concealment method
during the interval.
* Method of Measurement or Calculation: The metric is based on
measurements that are typically made at the time that a video
frame is decoded and rendered for playout. It is calculated by
summing the impaired proportion of each video frame and
dividing by the number of frames during this period. The
impaired proportion of each video frame is obtained by dividing
the number of missing macroblocks from this video frame by the
<span class="grey">Huang Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
total macroblock number of the video frame, which is equivalent
to multiplying the result of the division by 256, limiting the
maximum value to 255 (to avoid overflow), and taking the
integer part.
* Units of Measurement: This metric is expressed as a fixed-point
number with the binary point at the left edge of the field.
* Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream.
* Measurement Timing: See paragraph 1 of <a href="#section-4">Section 4</a>.
* Use and Applications: These metrics are applicable to video
applications of RTP and the video component of audio/video
applications in which packet loss concealment mechanisms are
incorporated into the receiving endpoint to mitigate the impact
of network impairments on QoE.
e. Mean Concealed Video Frame Proportion Metric
* Metric Name: Mean Concealed Video Frame Proportion Metric
* Metric Description: Mean proportion of each video frame to
which loss concealment (using Video Loss Concealment Method
Type) was applied during the interval.
* Method of Measurement or Calculation: The metric is based on
measurements that are typically made at the time that a video
frame is decoded and rendered for playout. It is calculated by
summing the concealed proportion of each video frame and
dividing by the number of frames during this period. The
concealed proportion of each video frame is obtained by
dividing the number of concealed macroblocks from this video
frame by the total macroblock number of the video frame, which
is equivalent to multiplying the result of the division by 256,
limiting the maximum value to 255 (to avoid overflow), and
taking the integer part.
* Units of Measurement: This metric is expressed as a fixed-point
number with the binary point at the left edge of the field.
* Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream.
* Measurement Timing: See paragraph 1 of <a href="#section-4">Section 4</a>.
<span class="grey">Huang Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
* Use and Applications: These metrics are applicable to video
applications of RTP and the video component of audio/video
applications in which packet loss concealment mechanisms are
incorporated into the receiving endpoint to mitigate the impact
of network impairments on QoE.
f. Fraction of Video Frames Subject to Concealment Metric
* Metric Name: Fraction of Video Frames Subject to Concealment
Metric
* Metric Description: Proportion of concealed video frames to
which loss concealment (using the Video Loss Concealment Method
Type) was applied compared to the total number of frames during
the interval.
* Method of Measurement or Calculation: The metric is based on
measurements that are typically made at the time that a video
frame is decoded and rendered for playout. This metric is
calculated by dividing the number of frames to which loss
concealment (using Video Loss Concealment Method Type) was
applied by the total number of frames. It is equivalent to
multiplying the result of the division by 256, limiting the
maximum value to 255 (to avoid overflow), and taking the
integer part.
* Units of Measurement: This metric is expressed as a fixed-
point number with the binary point at the left edge of the
field.
* Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream.
* Measurement Timing: See paragraph 1 of <a href="#section-4">Section 4</a>.
* Use and Applications: These metrics are applicable to video
applications of RTP and the video component of audio/video
applications in which packet loss concealment mechanisms are
incorporated into the receiving endpoint to mitigate the impact
of network impairments on QoE.
<span class="grey">Huang Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7867">RFC 7867</a> Video LC Metrics for RTCP XR July 2016</span>
Acknowledgements
The author would like to thank Colin Perkins and Roni Even for their
valuable comments.
Authors' Addresses
Rachel Huang
Huawei
101 Software Avenue, Yuhua District
Nanjing 210012
China
Email: rachel.huang@huawei.com
Huang Standards Track [Page 16]
</pre>
|
