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
|
<pre>Network Working Group F. de Bont
Request for Comments: 5691 Philips Electronics
Updates: <a href="./rfc3640">3640</a> S. Doehla
Category: Standards Track Fraunhofer IIS
M. Schmidt
Dolby Laboratories
R. Sperschneider
Fraunhofer IIS
October 2009
<span class="h1">RTP Payload Format for Elementary Streams</span>
<span class="h1">with MPEG Surround Multi-Channel Audio</span>
Abstract
This memo describes extensions for the RTP payload format defined in
<a href="./rfc3640">RFC 3640</a> for the transport of MPEG Surround multi-channel audio.
Additional Media Type parameters are defined to signal backwards-
compatible transmission inside an MPEG-4 Audio elementary stream. In
addition, a layered transmission scheme that doesn't use the MPEG-4
systems framework is presented to transport an MPEG Surround
elementary stream via RTP in parallel with an RTP stream containing
the downmixed audio data.
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 BSD License.
<span class="grey">de Bont, 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="./rfc5691">RFC 5691</a> Transport of MPEG Surround October 2009</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Conventions .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Definitions and Abbreviations ...................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Definitions ................................................<a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. Abbreviations ..............................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Transport of MPEG Surround ......................................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Embedded Spatial Audio Data in AAC Payloads ................<a href="#page-4">4</a>
<a href="#section-4.2">4.2</a>. MPEG Surround Elementary Stream ............................<a href="#page-5">5</a>
<a href="#section-4.2.1">4.2.1</a>. Low Bitrate MPEG Surround ...........................<a href="#page-7">7</a>
<a href="#section-4.2.2">4.2.2</a>. High Bitrate MPEG Surround ..........................<a href="#page-8">8</a>
<a href="#section-5">5</a>. IANA Considerations .............................................<a href="#page-8">8</a>
<a href="#section-5.1">5.1</a>. Media Type Registration ....................................<a href="#page-9">9</a>
<a href="#section-5.2">5.2</a>. Registration of Mode Definitions with IANA .................<a href="#page-9">9</a>
<a href="#section-5.3">5.3</a>. Usage of SDP ..............................................<a href="#page-10">10</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-10">10</a>
<a href="#section-7">7</a>. References .....................................................<a href="#page-11">11</a>
<a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-11">11</a>
<a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
MPEG Surround (Spatial Audio Coding, SAC) [<a href="#ref-23003-1" title=""ISO/IEC International Standard 23003-1 - MPEG Surround (MPEG D)"">23003-1</a>] is an
International Standard that was finalized by MPEG in January 2007.
It is capable of re-creating N channels based on M < N transmitted
channels and additional control data. In the preferred modes of
operating the Spatial Audio Coding system, the M channels can either
be a single mono channel or a stereo channel pair. The control data
represents a significantly lower data rate than the data rate
required for transmitting all N channels, making the coding very
efficient while at the same time ensuring compatibility with M
channel devices.
The MPEG Surround standard incorporates a number of tools that enable
features that allow for broad application of the standard. A key
feature is the ability to scale the spatial image quality gradually
from very low spatial overhead towards transparency. Another key
feature is that the decoder input can be made compatible to existing
matrixed surround technologies.
As an example, for 5.1 multi-channel audio, the MPEG Surround encoder
creates a stereo (or mono) downmix signal and spatial information
describing the full 5.1 material in a highly efficient, parameterised
format. The spatial information is transmitted alongside the
downmix.
<span class="grey">de Bont, 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="./rfc5691">RFC 5691</a> Transport of MPEG Surround October 2009</span>
By using MPEG Surround, existing services can easily be upgraded to
provide surround sound in a backwards-compatible fashion. While a
stereo decoder in an existing legacy consumer device ignores the MPEG
Surround data and plays back the stereo signal without any quality
degradation, an MPEG-Surround-enabled decoder will deliver high
quality, multi-channel audio.
The MPEG Surround decoder can operate in modes that render the multi-
channel signal to multi-channel or stereo output, or it can operate
in a two-channel headphone mode to produce a virtual surround output
signal.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions</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>. Definitions and Abbreviations</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Definitions</span>
This memo makes use of the definitions specified in [<a href="#ref-14496-1" title=""ISO/IEC International Standard 14496-1 - Coding of audio-visual objects, Part 1 Systems"">14496-1</a>],
[<a href="#ref-14496-3" title=""ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio"">14496-3</a>], [<a href="#ref-23003-1" title=""ISO/IEC International Standard 23003-1 - MPEG Surround (MPEG D)"">23003-1</a>], and [<a href="./rfc3640" title=""RTP Payload Format for Transport of MPEG-4 Elementary Streams"">RFC3640</a>]. Frequently used terms are
summed up for convenience:
Access Unit: An MPEG Access Unit is the smallest data entity to
which timing information is attributed. In the case of audio, an
Access Unit is the smallest individually accessible portion of
coded audio data within an elementary stream.
AudioSpecificConfig(): Extends the class DecoderSpecificInfo(), as
defined in [<a href="#ref-14496-1" title=""ISO/IEC International Standard 14496-1 - Coding of audio-visual objects, Part 1 Systems"">14496-1</a>], when the objectType indication refers to a
stream complying with [<a href="#ref-14496-3" title=""ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio"">14496-3</a>]. AudioSpecificConfig() is used as
the configuration structure for MPEG-4 audio as specified in
[<a href="#ref-14496-3" title=""ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio"">14496-3</a>]. It contains the field audioObjectType, which
distinguishes between the different audio codecs defined in
[<a href="#ref-14496-3" title=""ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio"">14496-3</a>], general audio information (e.g., the sampling frequency
and number of channels), and further codec-dependent information
structures.
SpatialSpecificConfig(): Configuration structure for MPEG Surround
audio coding, as specified in [<a href="#ref-23003-1" title=""ISO/IEC International Standard 23003-1 - MPEG Surround (MPEG D)"">23003-1</a>]. An AudioSpecificConfig()
with an audioObjectType of value 30 contains a
SpatialSpecificConfig() structure.
<span class="grey">de Bont, 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="./rfc5691">RFC 5691</a> Transport of MPEG Surround October 2009</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Abbreviations</span>
AOT: Audio Object Type
AAC: Advanced Audio Coding
ASC: AudioSpecificConfig() structure
AU: Access Unit
HE AAC: High Efficiency AAC
PLI: Profile and Level Indication
SSC: SpatialSpecificConfig() structure
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Transport of MPEG Surround</span>
From a top-level perspective, MPEG Surround data can be subdivided
into configuration data contained in the SpatialSpecificConfig()
(SSC) and the SpatialFrame(), which contains the MPEG Surround
payload. The configuration data can be signaled in-band or out-of-
band. In the case of in-band signaling the SSC is conveyed in a
SacDataFrame() jointly with a SpatialFrame(). In the case of out-of-
band signaling, the SSC is transmitted to the decoder separately,
e.g., by Session Description Protocol (SDP) [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] means.
SpatialFrame()s may be transmitted either embedded into the downmix
stream (<a href="#section-4.1">Section 4.1</a>) or as individual elementary streams besides the
downmix audio stream (<a href="#section-4.2">Section 4.2</a>).
The buffer definition for AAC decoders limits the size of an AU, as
specified in [<a href="#ref-14496-3" title=""ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio"">14496-3</a>]. For high-bitrate applications that exceed
this limit, all MPEG Surround data MUST be put in a separate stream,
as defined in <a href="#section-4.2">Section 4.2</a>.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Embedded Spatial Audio Data in AAC Payloads</span>
[<a id="ref-14496-3">14496-3</a>] defines the extension_payload() as a mechanism for
transport of extension data inside AAC payloads. Typical extension
data include Spectral Band Replication (SBR) data and MPEG Surround
data, i.e., a SacDataFrame() in extension_payload()s of type
EXT_SAC_DATA. extension_payload()s reside inside the downmix AAC
elementary stream. The resulting single elementary stream is
transported as specified in [<a href="./rfc3640" title=""RTP Payload Format for Transport of MPEG-4 Elementary Streams"">RFC3640</a>]. As AAC decoders are required
to skip unknown extension data, MPEG Surround data can be embedded in
backwards-compatible fashion and be transported with the mechanism
already described in [<a href="./rfc3640" title=""RTP Payload Format for Transport of MPEG-4 Elementary Streams"">RFC3640</a>].
The SacDataFrame() includes a SpatialFrame() and an optional header
that contains an SSC. Any SSC in a SacDataFrame() MUST be identical
to the SSC conveyed via SDP for that stream.
<span class="grey">de Bont, 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="./rfc5691">RFC 5691</a> Transport of MPEG Surround October 2009</span>
No new mode is introduced for SpatialFrame()s being embedded into AAC
payloads. Either the mode AAC-lbr or the mode AAC-hbr SHOULD be
used. The additional Media Type parameters, as defined in
<a href="#section-5.1">Section 5.1</a>, SHOULD be present when SpatialFrame()s are embedded into
AAC payloads.
For example:
m=audio 5000 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/48000/2
a=fmtp:96 streamType=5; profile-level-id=44; mode=AAC-hbr; config=131
056E598; sizeLength=13; indexLength=3; indexDeltaLength=3; constant
Duration=2048; MPS-profile-level-id=55; MPS-config=F1B4CF920442029B
501185B6DA00;
In this example, the stream specifies the HE AAC Profile at Level 2
[Profile and Level Indication (PLI) 44] and the config string
contains the hexadecimal representation of the HE AAC ASC
[audioObjectType=2 (AAC LC); extensionAudioObjectType=5 (SBR);
samplingFrequencyIndex=0x6 (24kHz);
extensionSamplingFrequencyIndex=0x3 (48kHz); channelConfiguration=2
(2.0 channels)] of the downmix AAC elementary stream that is using
explicit backwards-compatible signaling.
Furthermore, the stream specifies the MPEG Surround Baseline Profile
at Level 3 (PLI55) and the MPS-config string contains the hexadecimal
representation of the MPEG Surround ASC [audioObjectType=30 (MPEG
Surround); samplingFrequencyIndex=0x3 (48kHz); channelConfiguration=6
(5.1 channels); sacPayloadEmbedding=1; SSC=(48 kHz; 32 slots; 525
tree; ResCoding=1; ResBands=[0,13,13,13])].
Note that the a=fmtp line of the example above has been wrapped to
fit the page; it would comprise a single line in the SDP file.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. MPEG Surround Elementary Stream</span>
MPEG Surround SpatialFrame()s can be present in an individual
elementary stream. This stream complements the stream containing the
downmix audio data, which may be coded by an arbitrary coding scheme.
MPEG Surround elementary streams are packetized as specified in
[<a href="./rfc3640" title=""RTP Payload Format for Transport of MPEG-4 Elementary Streams"">RFC3640</a>]. The mode signaled and used for an MPEG Surround
elementary stream MUST be either MPS-hbr or MPS-lbr. The MPS-hbr
mode SHALL be used when the frame size may exceed 63 bytes, e.g.,
when high-bitrate residual coding is in use.
The dependency relationships between the MPEG Surround elementary
stream and the downmix stream are signaled as specified in [<a href="./rfc5583" title=""Signaling Media Decoding Dependency in the Session Description Protocol (SDP)"">RFC5583</a>].
<span class="grey">de Bont, 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="./rfc5691">RFC 5691</a> Transport of MPEG Surround October 2009</span>
The media clocks of the MPEG Surround elementary stream and the
downmix stream SHALL operate in the same clock domain, i.e., the
clocks are derived from a common clock and MUST NOT drift. RTCP
sender reports MUST indicate that the stream timestamps are not
drifting, i.e., that a single sender report for each stream is
sufficient to establish unambiguous timing. The sampling rate of the
MPEG Surround signal and the decoded downmix signal MUST be
identical.
If HE AAC is used as the coding scheme for the downmix, the RTP
clock-rate of the downmix MAY be the sampling rate of the AAC core,
i.e., the clock-rate of the MPEG Surround elementary stream is an
integer multiple of the clock-rate of the downmix stream.
Note that separate RTP streams have different random RTP timestamp
offsets, and therefore RTCP MUST be used to synchronize the coded
downmix audio data and the MPEG Surround elementary stream.
For example:
a=group:DDP L1 L2
m=audio 5000 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/48000/2
a=fmtp:96 streamType=5; profile-level-id=44; mode=AAC-hbr; config=2B1
18800; sizeLength=13; indexLength=3; indexDeltaLength=3; constantDu
ration=2048
a=mid:L1
m=audio 5002 RTP/AVP 97
a=rtpmap:97 mpeg4-generic/48000/6
a=fmtp:97 streamType=5; profile-level-id=55; mode=MPS-hbr; config=F1B
0CF920460029B601189E79E70; sizeLength=13; indexLength=3; indexDelt
aLength=3; constantDuration=2048
a=mid:L2
a=depend:97 lay L1:96
In this example, the first stream specifies the HE AAC Profile at
Level 2 (PLI44) and the config string contains the hexadecimal
representation of the HE AAC ASC [audioObjectType=2 (AAC LC);
extensionAudioObjectType=5 (SBR); samplingFrequencyIndex=0x6 (24kHz);
extensionSamplingFrequencyIndex=0x3 (48kHz); channelConfiguration=2
(2.0 channels)].
<span class="grey">de Bont, 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="./rfc5691">RFC 5691</a> Transport of MPEG Surround October 2009</span>
The second stream specifies Baseline MPEG Surround Profile at Level 3
(PLI55) and the config string contains the hexadecimal representation
of the ASC [AOT=30(MPEG Surround); 48 kHz; 5.1-ch;
sacPayloadEmbedding=0; SSC=(48 kHz; 32 slots; 525 tree; ResCoding=1;
ResBands=[7,7,7,7])].
Note that the a=fmtp lines of the example above have been wrapped to
fit the page; they would each comprise a single line in the SDP file.
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Low Bitrate MPEG Surround</span>
This mode is signaled by mode=MPS-lbr. This mode supports the
transport of one or more complete Access Units, each consisting of a
single MPEG Surround SpatialFrame(). The AUs can be variably sized
and interleaved. The maximum size of a SpatialFrame() is 63 bytes.
Fragmentation MUST NOT be used in this mode. Receivers MUST support
de-interleaving.
The payload configuration is the same as in the AAC-lbr mode. It
consists of the AU Header Section, followed by concatenated AUs.
Note that Access Units are byte-aligned. The Auxiliary Section MUST
be empty in the MPS-lbr mode. The 1-octet AU-header MUST provide:
1. the size of each AAC frame, encoded as 6 bits.
2. 2 bits of index information for computing the sequence (and hence
timing) of each SpatialFrame().
The concatenated AU Header Section MUST be preceded by the 16-bit AU-
headers-length field.
In addition to the required Media format parameters, the following
parameters MUST be present with fixed values: sizeLength (fixed value
6), indexLength (fixed value 2), and indexDeltaLength (fixed value
2). The parameter maxDisplacement MUST be present when interleaving.
SpatialFrame()s always have a fixed duration per AU; the fixed
duration MUST be signaled by the Media format parameter
constantDuration.
The value of the "config" parameter is the hexadecimal representation
of the ASC, as defined in [<a href="#ref-14496-3" title=""ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio"">14496-3</a>], with an AOT of 30 and the
sacPayloadEmbedding flag set to 0.
The "profile-level-id" parameter SHALL contain a valid PLI for MPEG
Surround, as specified in [<a href="#ref-14496-3" title=""ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio"">14496-3</a>].
<span class="grey">de Bont, 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="./rfc5691">RFC 5691</a> Transport of MPEG Surround October 2009</span>
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. High Bitrate MPEG Surround</span>
This mode is signaled by mode=MPS-hbr. This mode supports the
transportation of either one fragment of an Access Unit or one
complete AU or several complete AUs. Each AU consists of a single
MPEG Surround SpatialFrame(). The AUs can be variably sized and
interleaved. The maximum size of a SpatialFrame() is 8191 bytes.
Receivers MUST support de-interleaving.
The payload configuration is the same as in the AAC-hbr mode. It
consists of the AU Header Section, followed by either one
SpatialFrame(), a fragment of a SpatialFrame(), or several
concatenated SpatialFrame()s. Note that Access Units are byte-
aligned. The Auxiliary Section MUST be empty in the MPS-hbr mode.
The 2-octet AU-header MUST provide:
1. the size of each AAC frame, encoded as 13 bits.
2. 3 bits of index information for computing the sequence (and hence
timing) of each SpatialFrame(), i.e., the AU-Index or AU-Index-
delta field.
Each AU-Index field MUST be coded with the value 0. The concatenated
AU Header Section MUST be preceded by the 16-bit AU-headers-length
field.
In addition to the required Media format parameters, the following
parameters MUST be present with fixed values: sizeLength (fixed value
13), indexLength (fixed value 3), and indexDeltaLength (fixed value
3). The parameter maxDisplacement MUST be present when interleaving.
SpatialFrame()s always have a fixed duration per AU; the fixed
duration MUST be signaled by the Media format parameter
constantDuration.
The value of the "config" parameter is the hexadecimal representation
of the ASC, as defined in [<a href="#ref-14496-3" title=""ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio"">14496-3</a>], with an AOT of 30 and the
sacPayloadEmbedding flag set to 0.
The "profile-level-id" parameter SHALL contain a valid PLI for MPEG
Surround, as specified in [<a href="#ref-14496-3" title=""ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio"">14496-3</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
This memo defines additional optional format parameters to the Media
type "audio" and its subtype "mpeg4-generic". These parameters SHALL
only be used in combination with the AAC-lbr or AAC-hbr modes (cf.
<a href="./rfc3640#section-3.3">Section 3.3 of [RFC3640]</a>) of "mpeg4-generic".
<span class="grey">de Bont, 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="./rfc5691">RFC 5691</a> Transport of MPEG Surround October 2009</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Media Type Registration</span>
This memo defines the following additional optional parameters, which
SHALL be used if MPEG Surround data is present inside the payload of
an AAC elementary stream.
MPS-profile-level-id: A decimal representation of the MPEG Surround
Profile and Level indication as defined in [<a href="#ref-14496-3" title=""ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio"">14496-3</a>]. This
parameter MUST be used in the capability exchange or session
set-up procedure to indicate the MPEG Surround Profile and Level
that the decoder must be capable of in order to decode the stream.
MPS-config: A hexadecimal representation of an octet string that
expresses the AudioSpecificConfig (ASC), as defined in [<a href="#ref-14496-3" title=""ISO/IEC International Standard 14496-3 - Coding of audio-visual objects, Part 3 Audio"">14496-3</a>],
for MPEG Surround. The ASC is mapped onto the hexadecimal octet
string in a most significant bit (MSB)-first basis. The AOT in
this ASC SHALL have the value 30. The SSC inside the ASC MUST
have the sacPayloadEmbedding flag set to 1.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Registration of Mode Definitions with IANA</span>
This section of this memo requests the registration of the "MPS-hbr"
value and the "MPS-lbr" value for the "mode" parameter of the "mpeg4-
generic" media subtype within the media type "audio". The "mpeg4-
generic" media subtype is defined in [<a href="./rfc3640" title=""RTP Payload Format for Transport of MPEG-4 Elementary Streams"">RFC3640</a>], and [<a href="./rfc3640" title=""RTP Payload Format for Transport of MPEG-4 Elementary Streams"">RFC3640</a>] defines
a repository for the "mode" parameter. This memo registers the modes
"MPS-hbr" and "MPS-lbr" to support MPEG Surround elementary streams.
Media type name:
audio
Subtype name:
mpeg4-generic
Required parameters:
The "mode" parameter is required by [<a href="./rfc3640" title=""RTP Payload Format for Transport of MPEG-4 Elementary Streams"">RFC3640</a>]. This memo
specifies the additional modes "MPS-hbr" and "MPS-lbr", in
accordance with [<a href="./rfc3640" title=""RTP Payload Format for Transport of MPEG-4 Elementary Streams"">RFC3640</a>].
Optional parameters:
For the modes "AAC-hbr" and "AAC-lbr", this memo specifies the
additional optional parameters "MPS-profile-level-id" and "MPS-
config". See <a href="#section-4.1">Section 4.1</a> for usage details.
<span class="grey">de Bont, 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="./rfc5691">RFC 5691</a> Transport of MPEG Surround October 2009</span>
Optional parameters for the modes "MPS-hbr" and "MPS-lbr" may be
used as specified in [<a href="./rfc3640" title=""RTP Payload Format for Transport of MPEG-4 Elementary Streams"">RFC3640</a>]. The optional parameters "MPS-
profile-level-id" and "MPS-config" SHALL NOT be used for the modes
"MPS-hbr" and "MPS-lbr".
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Usage of SDP</span>
It is assumed that the Media format parameters are conveyed via an
SDP message, as specified in <a href="./rfc3640#section-4.4">Section 4.4 of [RFC3640]</a>.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>], in the RTP payload format specification for
MPEG-4 elementary streams [<a href="./rfc3640" title=""RTP Payload Format for Transport of MPEG-4 Elementary Streams"">RFC3640</a>] (which is extended with this
memo), and in any applicable RTP profile. The main security
considerations for the RTP packet carrying the RTP payload format
defined within this memo are confidentiality, integrity, and source
authenticity. Confidentiality is achieved by encryption of the RTP
payload. Integrity of the RTP packets is achieved through a suitable
cryptographic integrity-protection mechanism. Such a cryptographic
system may also allow the authentication of the source of the
payload. A suitable security mechanism for this RTP payload format
should provide confidentiality, integrity protection, and source
authentication capable of at least determining if an RTP packet is
from a member of the RTP session.
The AAC audio codec includes an extension mechanism to transmit extra
data within a stream that is gracefully skipped by decoders that do
not support this extra data. This covert channel may be used to
transmit unauthorized data in an otherwise valid stream.
Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the
application, the transport, and the signaling protocol employed.
Therefore, a single mechanism is not sufficient; although, if
suitable, usage of the Secure Real-time Transport Protocol (SRTP)
[<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>] is recommended. Other mechanisms that may be used are
IPsec [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>] and Transport Layer Security (TLS) [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] (RTP
over TCP); other alternatives may exist.
<span class="grey">de Bont, 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="./rfc5691">RFC 5691</a> Transport of MPEG Surround October 2009</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-14496-1">14496-1</a>] MPEG, "ISO/IEC International Standard 14496-1 - Coding of
audio-visual objects, Part 1 Systems", 2004.
[<a id="ref-14496-3">14496-3</a>] MPEG, "ISO/IEC International Standard 14496-3 - Coding of
audio-visual objects, Part 3 Audio", 2009.
[<a id="ref-23003-1">23003-1</a>] MPEG, "ISO/IEC International Standard 23003-1 - MPEG
Surround (MPEG D)", 2007.
[<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>, March 1997.
[<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>, July 2003.
[<a id="ref-RFC3640">RFC3640</a>] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D.,
and P. Gentric, "RTP Payload Format for Transport of
MPEG-4 Elementary Streams", <a href="./rfc3640">RFC 3640</a>, November 2003.
[<a id="ref-RFC4566">RFC4566</a>] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", <a href="./rfc4566">RFC 4566</a>, July 2006.
[<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>, July 2009.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<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>, March 2004.
[<a id="ref-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August 2008.
<span class="grey">de Bont, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5691">RFC 5691</a> Transport of MPEG Surround October 2009</span>
Authors' Addresses
Frans de Bont
Philips Electronics
High Tech Campus 5
5656 AE Eindhoven,
NL
Phone: ++31 40 2740234
EMail: frans.de.bont@philips.com
Stefan Doehla
Fraunhofer IIS
Am Wolfmantel 33
91058 Erlangen,
DE
Phone: +49 9131 776 6042
EMail: stefan.doehla@iis.fraunhofer.de
Malte Schmidt
Dolby Laboratories
Deutschherrnstr. 15-19
90537 Nuernberg,
DE
Phone: +49 911 928 91 42
EMail: malte.schmidt@dolby.com
Ralph Sperschneider
Fraunhofer IIS
Am Wolfmantel 33
91058 Erlangen,
DE
Phone: +49 9131 776 6167
EMail: ralph.sperschneider@iis.fraunhofer.de
de Bont, et al. Standards Track [Page 12]
</pre>
|
