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
|
<pre>Internet Engineering Task Force (IETF) S. Wenger
Request for Comments: 8082 J. Lennox
Updates: <a href="./rfc5104">5104</a> Vidyo, Inc.
Category: Standards Track B. Burman
ISSN: 2070-1721 M. Westerlund
Ericsson
March 2017
<span class="h1">Using Codec Control Messages in the RTP Audio-Visual Profile with</span>
<span class="h1">Feedback with Layered Codecs</span>
Abstract
This document updates <a href="./rfc5104">RFC 5104</a> by fixing a shortcoming in the
specification language of the Codec Control Message Full Intra
Request (FIR) description when using it with layered codecs. In
particular, a decoder refresh point needs to be sent by a media
sender when a FIR is received on any layer of the layered bitstream,
regardless of whether those layers are being sent in a single or in
multiple RTP flows. The other payload-specific feedback messages
defined in <a href="./rfc5104">RFC 5104</a> and <a href="./rfc4585">RFC 4585</a> (which was updated by <a href="./rfc5506">RFC 5506</a>) have
also been analyzed, and no corresponding shortcomings have been
found.
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/rfc8082">http://www.rfc-editor.org/info/rfc8082</a>.
<span class="grey">Wenger, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8082">RFC 8082</a> CCM for Layered Codecs March 2017</span>
Copyright Notice
Copyright (c) 2017 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.
Table of Contents
<a href="#section-1">1</a>. Introduction and Problem Statement . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Requirements Language . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Updated Definition of Decoder Refresh Point . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Full Intra Request for Layered Codecs . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. Identifying the Use of Layered Bitstreams (Informative) . . . <a href="#page-6">6</a>
6. Layered Codecs and Non-FIR Codec Control Messages
(Informative) . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6.1">6.1</a>. Picture Loss Indication (PLI) . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6.2">6.2</a>. Slice Loss Indication (SLI) . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6.3">6.3</a>. Reference Picture Selection Indication (RPSI) . . . . . . <a href="#page-7">7</a>
6.4. Temporal-Spatial Trade-Off Request and Notification
(TSTR/TSTN) . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6.5">6.5</a>. H.271 Video Back Channel Message (VBCM) . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<span class="grey">Wenger, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8082">RFC 8082</a> CCM for Layered Codecs March 2017</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction and Problem Statement</span>
The "Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)" [<a href="./rfc4585" title=""Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"">RFC4585</a>] and "Codec Control
Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"
[<a href="./rfc5104" title=""Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"">RFC5104</a>] specify a number of payload-specific feedback messages that
a media receiver can use to inform a media sender of certain
conditions or to make certain requests. The feedback messages are
being sent as RTCP receiver reports, and <a href="./rfc4585">RFC 4585</a> specifies timing
rules that make the use of those messages practical for time-
sensitive codec control.
Since the time those RFCs were developed, layered codecs have gained
in popularity and deployment. Layered codecs use multiple sub-
bitstreams called "layers" to represent the content in different
fidelities. Depending on the media codec and its RTP payload format
in use, a number of options exist on how to transport those layers in
RTP. Summarizing "A Taxonomy of Semantics and Mechanisms for Real-
Time Transport Protocol (RTP) Sources" [<a href="./rfc7656" title=""A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources"">RFC7656</a>]):
single layers or groups of layers may be sent in their own RTP
streams in Multiple RTP streams on a Single media Transport (MRST)
or Multiple RTP streams on Multiple media Transports (MRMT) mode;
using media-codec specific multiplexing mechanisms, multiple
layers may be sent in a single RTP stream in Single RTP stream on
a Single media Transport (SRST) mode.
The dependency relationship between layers in a truly layered,
pyramid-shaped bitstream forms a directed graph, with the base layer
at the root. Enhancement layers depend on the base layer and
potentially on other enhancement layers, and the target layer and all
layers it depends on have to be decoded jointly in order to recreate
the uncompressed media signal at the fidelity of the target layer.
Such a layering structure is assumed henceforth; for more exotic
layering structures, please see <a href="#section-5">Section 5</a>.
Implementation experience has shown that the Full Intra Request (FIR)
command as defined in [<a href="./rfc5104" title=""Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"">RFC5104</a>] is underspecified when used with
layered codecs and when more than one RTP stream is used to transport
the layers of a layered bitstream at a given fidelity. In
particular, from the [<a href="./rfc5104" title=""Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"">RFC5104</a>] specification language, it is not
clear whether a FIR received for only a single RTP stream of multiple
RTP streams covering the same layered bitstream necessarily triggers
the sending of a decoder refresh point (as defined in <a href="./rfc5104#section-2.2">[RFC5104],
Section 2.2</a>) for all layers, or only for the layer that is
transported in the RTP stream that the FIR request is associated
with.
<span class="grey">Wenger, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8082">RFC 8082</a> CCM for Layered Codecs March 2017</span>
This document fixes this shortcoming by:
a. Updating the definition of the decoder refresh point (as defined
in <a href="./rfc5104#section-2.2">[RFC5104], Section 2.2</a>) to cover layered codecs, in line with
the corresponding definitions used in a popular layered codec
format, namely H.264/SVC (Scalable Video Coding) [<a href="#ref-H.264" title=""Advanced video coding for generic audiovisual services"">H.264</a>].
Specifically, a decoder refresh point, in conjunction with
layered codecs, resets the state of the whole decoder, which
implies that it includes hard or gradual single-layer decoder
refresh for all layers;
b. Requiring a media sender to send a decoder refresh point after
the media sender has received a FIR over an RTCP stream
associated with any of the RTP streams over which a part of the
layered bitstream is transported;
c. Requiring that a media receiver send the FIR on the RTCP stream
associated with the base layer. The option of receiving FIR on
the enhancement-layer-associated RTCP stream as specified in
point b) above is kept for backward compatibility; and
d. Providing guidance on how to detect that a layered bitstream is
in use for which the above rules apply.
While, clearly, the reaction to FIR for layered codecs in [<a href="./rfc5104" title=""Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"">RFC5104</a>]
and the companion documents is underspecified, it appears that this
is not the case for any of the other payload-specific codec control
messages defined in [<a href="./rfc4585" title=""Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"">RFC4585</a>] and [<a href="./rfc5104" title=""Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"">RFC5104</a>]. A brief summary of the
analysis that led to this conclusion is also included in this
document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements Language</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">RFC 2119</a> [<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>. Updated Definition of Decoder Refresh Point</span>
The remainder of this section replaces the definition of decoder
refresh point in <a href="./rfc5104#section-2.2">Section 2.2 of [RFC5104]</a> in its entirety.
Decoder Refresh Point: A bit string, packetized in one or more RTP
packets, that completely resets the decoder to a known state.
<span class="grey">Wenger, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8082">RFC 8082</a> CCM for Layered Codecs March 2017</span>
Examples for "hard" single-layer decoder refresh points are Intra
pictures in H.261 [<a href="#ref-H.261" title=""Video codec for audiovisual services at p x 64 kbit/s"">H.261</a>], H.263 [<a href="#ref-H.263" title=""Video coding for low bit rate communication"">H.263</a>], MPEG-1 [<a href="#ref-MPEG-1" title=""Information technology -- Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s -- Part 2: Video"">MPEG-1</a>], MPEG-2
[<a href="#ref-MPEG-2" title=""Information technology -- Generic coding of moving pictures and associated audio information -- Part 2: Video"">MPEG-2</a>], and MPEG-4 [<a href="#ref-MPEG-4" title=""Information technology -- Coding of audio-visual objects -- Part 2: Visual"">MPEG-4</a>]; Instantaneous Decoder Refresh (IDR)
pictures in H.264 [<a href="#ref-H.264" title=""Advanced video coding for generic audiovisual services"">H.264</a>] and H.265 [<a href="#ref-H.265" title=""High efficiency video coding"">H.265</a>]; and keyframes in VP8
[<a href="./rfc6386" title=""VP8 Data Format and Decoding Guide"">RFC6386</a>] and VP9 [<a href="#ref-VP9-BITSTREAM">VP9-BITSTREAM</a>]. "Gradual" decoder refresh points
may also be used; see, for example, H.264 [<a href="#ref-H.264" title=""Advanced video coding for generic audiovisual services"">H.264</a>]. While both "hard"
and "gradual" decoder refresh points are acceptable in the scope of
this specification, in most cases the user experience will benefit
from using a "hard" decoder refresh point.
A decoder refresh point also contains all header information above
the syntactical level of the picture layer that is conveyed in-band.
In [<a href="#ref-H.264" title=""Advanced video coding for generic audiovisual services"">H.264</a>], for example, a decoder refresh point contains those
parameter set Network Adaptation Layer (NAL) units that generate
parameter sets necessary for the decoding of the following slice/data
partition NAL units. (That is, assuming the parameter sets have not
been conveyed out of band.)
When a layered codec is in use, the above definition -- in
particular, the requirement to completely reset the decoder to a
known state -- implies that the decoder refresh point includes hard
or gradual single-layer decoder refresh points for all layers.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Full Intra Request for Layered Codecs</span>
A media receiver or middlebox may decide to send a FIR command based
on the guidance provided in <a href="./rfc5104#section-4.3.1">Section 4.3.1 of [RFC5104]</a>. When sending
the FIR command, it MUST target the RTP stream that carries the base
layer of the layered bitstream, and this is done by setting the
Feedback Control Information (FCI) (and, in particular, the
synchronization source (SSRC) field therein) to refer to the SSRC of
the forward RTP stream that carries the base layer.
When a Full Intra Request command is received by the designated media
sender in the RTCP stream associated with any of the RTP streams in
which any layer of a layered bitstream are sent, the designated media
sender MUST send a decoder refresh point (<a href="#section-3">Section 3</a>) as defined above
at its earliest opportunity. The requirements related to congestion
control on the forward RTP streams as specified in Sections <a href="#section-3.5.1">3.5.1</a> and
5 of [<a href="./rfc5104" title=""Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"">RFC5104</a>] apply for the RTP streams both in isolation and
combined.
Note: the requirement to react to FIR commands associated with
enhancement layers is included for robustness and backward-
compatibility reasons.
<span class="grey">Wenger, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8082">RFC 8082</a> CCM for Layered Codecs March 2017</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Identifying the Use of Layered Bitstreams (Informative)</span>
The above modifications to <a href="./rfc5104">RFC 5104</a> unambiguously define how to deal
with FIR commands when layered bitstreams are in use. However, it is
surprisingly difficult to identify the use of a layered bitstream.
In general, it is expected that implementers know when layered
bitstreams (in its commonly understood sense: with inter-layer
prediction between pyramid-arranged layers) are in use and when not
and can therefore implement the above updates to <a href="./rfc5104">RFC 5104</a> correctly.
However, there are scenarios in which layered codecs are employed
creating non-pyramid-shaped bitstreams. Those scenarios may be
viewed as somewhat exotic today but clearly are supported by certain
video coding syntaxes, such as H.264/SVC. When blindly applying the
above rules to those non-pyramid-arranged layering structures,
suboptimal system behavior would result. Nothing would break, and
there would not be an interoperability failure, but the user
experience may suffer through the sending or receiving of decoder
refresh points at times or on parts of the bitstream that are
unnecessary from a user experience viewpoint. Therefore, this
informative section is included that provides the current
understanding of when a layered bitstream is in use and when not.
The key observation made here is that the RTP payload format
negotiated for the RTP streams, in isolation, is not necessarily an
indicator for the use of a layered bitstream. Some layered codecs
(including H.264/SVC) can form decodable bitstreams including only
(one or more) enhancement layers, without the base layer, effectively
creating simulcastable sub-bitstreams within a single scalable
bitstream (as defined in the video coding standard), but without
inter-layer prediction. In such a scenario, it is potentially,
though not necessarily, counterproductive to send a decoder refresh
point on all layers for that payload format and media source. It is
beyond the scope of this document to discuss optimized reactions to
FIRs received on RTP streams carrying such exotic bitstreams.
One good indication of the likely use of pyramid-shaped layering with
inter-layer prediction is when the various RTP streams are "bound"
together on the signaling level. In an SDP environment, this would
be the case if they are marked as being dependent on each other using
"The Session Description Protocol (SDP) Grouping Framework" [<a href="./rfc5888" title=""The Session Description Protocol (SDP) Grouping Framework"">RFC5888</a>]
and layer dependency [<a href="./rfc5583" title=""Signaling Media Decoding Dependency in the Session Description Protocol (SDP)"">RFC5583</a>].
<span class="grey">Wenger, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8082">RFC 8082</a> CCM for Layered Codecs March 2017</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Layered Codecs and Non-FIR Codec Control Messages (Informative)</span>
Between them, AVPF [<a href="./rfc4585" title=""Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"">RFC4585</a>] and Codec Control Messages [<a href="./rfc5104" title=""Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"">RFC5104</a>]
define a total of seven payload-specific feedback messages. For the
FIR command message, guidance has been provided above. In this
section, some information is provided with respect to the remaining
six codec control messages.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Picture Loss Indication (PLI)</span>
PLI is defined in <a href="./rfc4585#section-6.3.1">Section 6.3.1 of [RFC4585]</a>. The prudent response
to a PLI message received for an enhancement layer is to "repair"
that enhancement layer and all dependent enhancement layers through
appropriate source-coding-specific means. However, the reference
layer or layers used by the enhancement layer for which the PLI was
received do not require repair. The encoder can figure out by itself
what constitutes a dependent enhancement layer and does not need help
from the system stack in doing so. Thus, there is nothing that needs
to be specified herein.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Slice Loss Indication (SLI)</span>
SLI is defined in <a href="./rfc4585#section-6.3.2">Section 6.3.2 of [RFC4585]</a>. The current
understanding is that the prudent response to an SLI message received
for an enhancement layer is to "repair" the affected spatial area of
that enhancement layer and all dependent enhancement layers through
appropriate source-coding-specific means. As in PLI, the reference
layers used by the enhancement layer for which the SLI was received
do not need to be repaired. Again, as in PLI, the encoder can
determine by itself what constitutes a dependent enhancement layer
and does not need help from the system stack in doing so. Thus,
there is nothing that needs to be specified herein. SLI has seen
very little implementation and, as far as it is known, none in
conjunction with layered systems.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Reference Picture Selection Indication (RPSI)</span>
RPSI is defined in <a href="./rfc4585#section-6.3.3">Section 6.3.3 of [RFC4585]</a>. While a technical
equivalent of RPSI has been in use with non-layered systems for many
years, no implementations are known in conjunction of layered codecs.
The current understanding is that the reception of an RPSI message on
any layer indicating a missing reference picture forces the encoder
to appropriately handle that missing reference picture in the layer
indicated, and in all dependent layers. Thus, RPSI should work
without further need for specification language.
<span class="grey">Wenger, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8082">RFC 8082</a> CCM for Layered Codecs March 2017</span>
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. Temporal-Spatial Trade-Off Request and Notification (TSTR/TSTN)</span>
TSTR/TSTN are defined in Sections <a href="#section-4.3.2">4.3.2</a> and <a href="#section-4.3.3">4.3.3</a> of [<a href="./rfc5104" title=""Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"">RFC5104</a>],
respectively. The TSTR request communicates guidance of the
preferred trade-off between spatial quality and frame rate. A
technical equivalent of TSTR/TSTN has seen deployment for many years
in non-scalable systems.
TSTR and TSTN messages include an SSRC target, which, similarly to
FIR, may refer to an RTP stream carrying a base layer, an enhancement
layer, or multiple layers. Therefore, the current understanding is
that the semantics of the message applies to the layers present in
the targeted RTP stream.
It is noted that per-layer TSTR/TSTN is a mechanism that is, in some
ways, counterproductive in a system using layered codecs. Given a
sufficiently complex layered bitstream layout, a sending system has
flexibility in adjusting the spatio/temporal quality balance by
adding and removing temporal, spatial, or quality enhancement layers.
At present, it is unclear whether an allowed (or even recommended)
option to the reception of a TSTR is to adjust the bit allocation
within the layer(s) present in the addressed RTP stream or to adjust
the layering structure accordingly -- which can involve more than
just the addressed RTP stream.
Until there is a sufficient critical mass of implementation practice,
it is probably prudent for an implementer not to assume either of the
two options or any middle ground that may exist between the two.
Instead, it is suggested that an implementation be liberal in
accepting TSTR messages and upon receipt, responding in TSTN
indicating "no change". Further, it is suggested that new
implementations do not send TSTR messages except when operating in
SRST mode as defined in [<a href="./rfc7656" title=""A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources"">RFC7656</a>]. Finally, implementers are
encouraged to contribute to the IETF documentation of any
implementation requirements that make per-layer TSTR/TSTN useful.
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. H.271 Video Back Channel Message (VBCM)</span>
VBCM is defined in <a href="./rfc5104#section-4.3.4">Section 4.3.4 of [RFC5104]</a>. What was said above
for RPSI (<a href="#section-6.3">Section 6.3</a>) applies here as well.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
This memo includes no request to IANA.
<span class="grey">Wenger, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8082">RFC 8082</a> CCM for Layered Codecs March 2017</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
The security considerations of AVPF [<a href="./rfc4585" title=""Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"">RFC4585</a>] (as updated by "Support
for Reduced-Size Real-Time Transport Control Protocol (RTCP):
Opportunities and Consequences" [<a href="./rfc5506" title=""Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences"">RFC5506</a>]) and Codec Control Messages
[<a href="./rfc5104" title=""Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)"">RFC5104</a>] apply. The clarified response to FIR does not introduce
additional security considerations.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.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-RFC4585">RFC4585</a>] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", <a href="./rfc4585">RFC 4585</a>,
DOI 10.17487/RFC4585, July 2006,
<<a href="http://www.rfc-editor.org/info/rfc4585">http://www.rfc-editor.org/info/rfc4585</a>>.
[<a id="ref-RFC5104">RFC5104</a>] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", <a href="./rfc5104">RFC 5104</a>, DOI 10.17487/RFC5104,
February 2008, <<a href="http://www.rfc-editor.org/info/rfc5104">http://www.rfc-editor.org/info/rfc5104</a>>.
[<a id="ref-RFC5506">RFC5506</a>] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", <a href="./rfc5506">RFC 5506</a>, DOI 10.17487/RFC5506, April
2009, <<a href="http://www.rfc-editor.org/info/rfc5506">http://www.rfc-editor.org/info/rfc5506</a>>.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-H.261">H.261</a>] ITU-T, "Video codec for audiovisual services at p x 64
kbit/s", ITU-T Recommendation H.261, March 1993,
<<a href="http://handle.itu.int/11.1002/1000/1088">http://handle.itu.int/11.1002/1000/1088</a>>.
[<a id="ref-H.263">H.263</a>] ITU-T, "Video coding for low bit rate communication",
ITU-T Recommendation H.263, January 2005,
<<a href="http://handle.itu.int/11.1002/1000/7497">http://handle.itu.int/11.1002/1000/7497</a>>.
[<a id="ref-H.264">H.264</a>] ITU-T, "Advanced video coding for generic audiovisual
services", ITU-T Recommendation H.264, Version 11, October
2016, <<a href="http://handle.itu.int/11.1002/1000/12904">http://handle.itu.int/11.1002/1000/12904</a>>.
<span class="grey">Wenger, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8082">RFC 8082</a> CCM for Layered Codecs March 2017</span>
[<a id="ref-H.265">H.265</a>] ITU-T, "High efficiency video coding", ITU-T
Recommendation H.265, Version 4, December 2016,
<<a href="http://handle.itu.int/11.1002/1000/12905">http://handle.itu.int/11.1002/1000/12905</a>>.
[<a id="ref-MPEG-1">MPEG-1</a>] ISO/IEC, "Information technology -- Coding of moving
pictures and associated audio for digital storage media at
up to about 1,5 Mbit/s -- Part 2: Video", ISO/
IEC 11172-2:1993, August 1993.
[<a id="ref-MPEG-2">MPEG-2</a>] ISO/IEC, "Information technology -- Generic coding of
moving pictures and associated audio information -- Part
2: Video", ISO/IEC 13818-2:2013, October 2013.
[<a id="ref-MPEG-4">MPEG-4</a>] ISO/IEC, "Information technology -- Coding of audio-visual
objects -- Part 2: Visual", ISO/IEC 14496-2:2004, June
2004.
[<a id="ref-RFC5583">RFC5583</a>] Schierl, T. and S. Wenger, "Signaling Media Decoding
Dependency in the Session Description Protocol (SDP)",
<a href="./rfc5583">RFC 5583</a>, DOI 10.17487/RFC5583, July 2009,
<<a href="http://www.rfc-editor.org/info/rfc5583">http://www.rfc-editor.org/info/rfc5583</a>>.
[<a id="ref-RFC5888">RFC5888</a>] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", <a href="./rfc5888">RFC 5888</a>,
DOI 10.17487/RFC5888, June 2010,
<<a href="http://www.rfc-editor.org/info/rfc5888">http://www.rfc-editor.org/info/rfc5888</a>>.
[<a id="ref-RFC6386">RFC6386</a>] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,
Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding
Guide", <a href="./rfc6386">RFC 6386</a>, DOI 10.17487/RFC6386, November 2011,
<<a href="http://www.rfc-editor.org/info/rfc6386">http://www.rfc-editor.org/info/rfc6386</a>>.
[<a id="ref-RFC7656">RFC7656</a>] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", <a href="./rfc7656">RFC 7656</a>,
DOI 10.17487/RFC7656, November 2015,
<<a href="http://www.rfc-editor.org/info/rfc7656">http://www.rfc-editor.org/info/rfc7656</a>>.
[<a id="ref-VP9-BITSTREAM">VP9-BITSTREAM</a>]
Grange, A., de Rivaz, P., and J. Hunt, "VP9 Bitstream &
Decoding Process Specification", Version 0.6, March 2016,
<<a href="https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf">https://storage.googleapis.com/downloads.webmproject.org/</a>
<a href="https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf">docs/vp9/vp9-bitstream-specification-</a>
<a href="https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf">v0.6-20160331-draft.pdf</a>>.
<span class="grey">Wenger, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8082">RFC 8082</a> CCM for Layered Codecs March 2017</span>
Acknowledgements
The authors want to thank Mo Zanaty for useful discussions.
Authors' Addresses
Stephan Wenger
Vidyo, Inc.
Email: stewe@stewe.org
Jonathan Lennox
Vidyo, Inc.
Email: jonathan@vidyo.com
Bo Burman
Ericsson
Kistavagen 25
SE - 164 80 Kista
Sweden
Email: bo.burman@ericsson.com
Magnus Westerlund
Ericsson
Farogatan 2
SE - 164 80 Kista
Sweden
Phone: +46107148287
Email: magnus.westerlund@ericsson.com
Wenger, et al. Standards Track [Page 11]
</pre>
|
