RFC 5584
RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family
RFC 5584: RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family 🎀
Okay bestie, let's do the title block first because it's giving main character energy. 💅 This is RFC 5584, titled exactly as shown above. The authors are M. Hatanaka and J. Matsumoto, both from Sony Corporation. It's a Standards Track document, dated July 2009. The header doesn't list anything it obsoletes or updates, so this one isn't replacing or patching any other RFC, at least according to that block. 🌸
Abstract ✨
So the vibe here is efficient and flexible audio transport 🎧. This doc describes an RTP payload format (basically the rules for how the audio gets packed up 📦) for audio encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent upgrades to ATRAC support high-quality audio with multiple channels 🔥. The format also covers data fragmentation, basic redundancy measures, and a variation on scalable streaming. Iconic. 👑
Status of This Memo 🦋
Here's the deal with the status stuff: this document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💜. If you want to know where this protocol stands in standardization, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 🌈.
Copyright Notice 🧚
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as in effect on the date this document was published. Please read these carefully, because they describe your rights and restrictions for this document. You can find them at http://trustee.ietf.org/license-info. 📜
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English. 🙈
Table of Contents 🗂️
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Codec-Specific Details ..........................................3
4. RTP Packetization and Transport of ATRAC-Family Streams .........4
4.1. ATRAC Frames ...............................................4
4.2. Concatenation of Frames ....................................4
4.3. Frame Fragmentation ........................................4
4.4. Transmission of Redundant Frames ...........................4
4.5. Scalable Lossless Streaming (High-Speed Transfer Mode) .....5
4.5.1. Scalable Multiplexed Streaming ......................5
4.5.2. Scalable Multi-Session Streaming ....................5
5. Payload Format ..................................................6
5.1. Global Structure of Payload Format .........................6
5.2. Usage of RTP Header Fields .................................7
5.3. RTP Payload Structure ......................................8
5.3.1. Usage of ATRAC Header Section .......................8
5.3.2. Usage of ATRAC Frames Section .......................9
6. Packetization Examples .........................................12
6.1. Example Multi-Frame Packet ................................12
6.2. Example Fragmented ATRAC Frame ............................13
7. Payload Format Parameters ......................................14
7.1. ATRAC3 Media Type Registration ............................14
7.2. ATRAC-X Media Type Registration ...........................16
7.3. ATRAC Advanced Lossless Media Type Registration ...........18
7.4. Channel Mapping Configuration Table .......................20
7.5. Mapping Media Type Parameters into SDP ....................21
7.5.1. For Media Subtype ATRAC3 ...........................21
7.5.2. For Media Subtype ATRAC-X ..........................21
7.5.3. For Media Subtype ATRAC Advanced Lossless ..........22
7.6. Offer/Answer Model Considerations .........................22
7.6.1. For All Three Media Subtypes .......................22
7.6.2. For Media Subtype ATRAC3 ...........................23
7.6.3. For Media Subtype ATRAC-X ..........................23
7.6.4. For Media Subtype ATRAC Advanced Lossless ..........23
7.7. Usage of Declarative SDP ..................................24
7.8. Example SDP Session Descriptions ..........................24
7.9. Example Offer/Answer Exchange .............................26
8. IANA Considerations ............................................28
9. Security Considerations ........................................28
10. Considerations on Correct Decoding ............................28
10.1. Verification of the Packets ..............................28
10.2. Validity Checking of the Packets .........................29
11. References ....................................................29
11.1. Normative References .....................................29
11.2. Informative References ...................................301. Introduction 🎶
The ATRAC family of perceptual audio codecs is built to handle lots of needs for high-quality, low-bit-rate audio transfer 💖. You'll find ATRAC in tons of consumer and professional stuff, like MD players, CD players, voice recorders, and mobile phones 📱.
Recent advances in ATRAC let multiple channels of audio get encoded in customizable groupings 🎚️. This should open the door to future expansions in scaled streaming, giving the most flexibility for streaming any one of the ATRAC family member codecs. BUT (and this is important, bestie 🫶) this payload format doesn't tell the codecs apart at the packet level.
This simplified payload format carries only the basic info you need to take apart a packet of ATRAC audio so you can decode it. It also has basic support for fragmentation and redundancy 🦋.
2. Conventions Used in This Document 📚
Okay so the key words in this document are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". They're to be read as described in RFC 2119 [4]. 🤓
3. Codec-Specific Details 🌸
Early versions of the ATRAC codec only handled two channels of audio at a 44.1 kHz sampling frequency, with typical bit-rates between 66 kbps and 132 kbps 🎵. The latest version is a whole glow-up: up to 8 channels of audio, sampling frequencies up to 96 kHz, and a lossless encoding option that can be sent in either a scalable format (also called High-Speed Transfer mode) or a standard format (aka Standard mode) ✨. The feasible bit-rate range has expanded too, going from as low as 8 kbps all the way up to 1400 kbps in lossy encoding modes 🚀.
Depending on which version of ATRAC you're using, the sample-frame size is 512, 1024, or 2048 samples 🔢. Lossy and Standard mode lossless formats are encoded as sequential single audio frames. High-Speed Transfer mode lossless data is different though, because it has two layers: a lossy base layer and an enhancement layer 🧁.
Multi-channel streaming is supported depending on the ATRAC version used, but all the encoded audio for a given time period lives inside a single frame. That means there's no interleaving or splitting of audio data on a per-channel basis, so you don't have to worry about that one 💅.
4. RTP Packetization and Transport of ATRAC-Family Streams 📦
4.1. ATRAC Frames 🎞️
To transport compressed audio data, ATRAC uses the concept of frames. ATRAC frames are the smallest data unit that timing information gets attributed to 🕰️. Frames are octet-aligned by definition.
4.2. Concatenation of Frames 🧺
It's often possible to carry multiple frames in one RTP packet, and that's super useful for audio 🙌. Say you're on a LAN with a 1500-byte MTU: an average of 7 complete 64 kbps ATRAC frames could fit in a single RTP packet, since each ATRAC frame would be about 200 bytes. ATRAC frames can be fixed or variable length. To make parsing easier when there are multiple frames in one RTP packet, the size of each frame is made known to the receiver by carrying the frame size for each contained frame "in-band" in the RTP packet 📏.
Now here's the part that keeps things simple for RTP receivers (the implementers will thank you 🫶). When multiple frames are carried in an RTP packet, each frame MUST be complete. In other words, the number of frames in an RTP packet MUST be integral. No half-frames allowed, bestie 🙅♀️.
4.3. Frame Fragmentation 🧩
The ATRAC codec can handle really big frames 🐘. Most IP networks have MTU sizes that are way smaller than the frame sizes ATRAC can handle, so this payload format lets you fragment an ATRAC frame across multiple RTP packets 🪓.
Again, to keep life easy for RTP receivers, an RTP packet MUST carry either one or more complete ATRAC frames or a single fragment of one ATRAC frame. Put differently, RTP packets MUST NOT contain fragments of multiple ATRAC frames, and they MUST NOT contain a mix of complete and fragmented frames. Not me being strict, just the rules 💀.
4.4. Transmission of Redundant Frames 🔁
RTP doesn't guarantee reliable transmission, so receipt of data isn't assured 😬. When a packet gets lost, you can end up with a "decoding gap" at the receiver. One way to fix this is to send time-shifted copies of ATRAC frames along with the current data 🕒. For a modest cost in latency and implementation complexity, you can get error resiliency to packet loss. For more details, see Section 5.3.2.1 and [12] 📖.
4.5. Scalable Lossless Streaming (High-Speed Transfer Mode) 🌈
ATRAC supports a variation on scalable encoding, so this payload format gives you a way to transmit essential data (also called the base layer) along with its enhancement data in two ways. You can multiplex them through one session, or separate them over two sessions 🎭.
Either way, only the base layer is essential for producing audio data. The enhancement layer carries the rest of the audio data needed to decode lossless audio. So if bandwidth is limited, the sender may choose not to transmit enhancement data, and the client still gets enough data to generate lossily-encoded audio through the base layer 🌙.
4.5.1. Scalable Multiplexed Streaming 🧵
In multiplexed streaming, the base layer and enhancement layer are coupled together in each packet, and only one session is used, as shown in Figure 1 🦋.
The packet MUST begin with the base layer. If both layers exist in a packet, the two layer types MUST interleave. (The only exception is when a packet has just the base layer or just the enhancement layer, which can happen at the start of a stream or during fragmentation 🙈.)
+----------------+ +----------------+ +----------------+
|Base|Enhancement|--|Base|Enhancement|--|Base|Enhancement| ...
+----------------+ +----------------+ +----------------+
N N+1 N+2 : PacketFigure 1. Multiplexed Structure 🍓
4.5.2. Scalable Multi-Session Streaming ✨
okay so in multi-session streaming, the base layer and the enhancement layer get sent over two separate sessions 🎀 this is lowkey so clever bc a client with bandwidth limits can grab just the base layer and still decode it, no drama 💖 see Figure 2 below.
Figure 2 🌸
Session 1:
+------+ +------+ +------+ +------+
| Base |--| Base |--| Base |--| Base | ...
+------+ +------+ +------+ +------+
N N+1 N+2 N+3 : Packet
Session 2:
+-------------+ +-------------+ +-------------+
| Enhancement |--| Enhancement |--| Enhancement | ...
+-------------+ +-------------+ +-------------+
N N+1 N+2 : Packet
Figure 2. Multi-Session Streamingbestie, the receiver REQUIRED to figure out which sessions are paired together 🫶 and for paired base and enhancement layer sessions, the CNAME bindings in the RTP Control Protocol (RTCP) session MUST be applied using the same CNAME so the mapping to the RTP source stays correct 💅
there might be other ways to sync the layers, but the timestamp SHOULD be used to line up the base layer with its enhancement 🧚 and both sessions MUST be synchronized using the info in the RTCP SR packets so the RTP timestamps match up 🦋
one more thing, and it's a big one 😭 if the enhancement layer's session data can't show up by presentation time, the decoder MUST decode the base layer session's data only and ignore the enhancement layer's data. no cap, that's just how it goes 💀
5. Payload Format 👑
5.1. Global Structure of Payload Format 🌈
the ATRAC payload is laid out like Figure 3 👇 the RTP payload after the RTP header has two octet-aligned data sections, and they're literally the whole vibe ✨
Figure 3 🎀
+------+--------------+-----------------------------+
|RTP | ATRAC Header | ATRAC Frames Section |
|Header| Section | (including redundant data) |
+------+--------------+-----------------------------+
< ---------------- RTP Packet Payload ------------- >
Figure 3. Structure of RTP Payload of ATRAC Familythe first section is the ATRAC Header, which has just one header with info for the whole packet 🦋 the second section is where the encoded ATRAC frames live. it can hold either a single fragment of one ATRAC frame or one or more complete ATRAC frames 💖 the ATRAC Frames Section MUST NOT be empty, periodt 💅 and if you're using the redundancy mechanism from Section 5.3.2.1, the redundant frame data can go in this section, and the timestamp MUST be set to the oldest redundant frame's timestamp 🫶
to get ATRAC's High-Speed Transfer mode lossless encoding, the RTP payload can be split across two sessions, with one carrying the essential base layer and the other carrying enhancement data 🚀 but either way, this same structure still applies 🌸
5.2. Usage of RTP Header Fields 🍓
here's the RTP Standard Header Part, Figure 4 👀
Figure 4 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. RTP Standard Header Partthe RTP Standard Header Part is laid out like Figure 4, so let's go field by field 🎀
Version(V): 2 bits 💜 it's always set to 2 🌸
Padding(P): 1 bit 🫧 if the padding bit is set, the packet has one or more extra padding octets at the end that are NOT part of the payload. the last octet of the padding is a count of how many padding octets to ignore, itself included 😭 padding can be needed by some encryption algorithms with fixed block sizes, or for carrying several RTP packets in a lower-layer protocol data unit (see [1]) ✨
Extension(X): 1 bit 🦋 this one's defined by the RTP profile being used 💅
CSRC count(CC): 4 bits 🌈 see RFC 3550 [1] 🫶
Marker (M): 1 bit 🍓 it's set to 1 if the packet is the first packet after a silence period; otherwise, it MUST be set to 0 🔥
Payload Type (PT): 7 bits 🧚 assigning an RTP payload type for this packet format is outside the scope of this document 🌸 it's specified by the RTP profile this payload format is used under, or signaled dynamically out-of-band (e.g., using the Session Description Protocol (SDP)) 💖
sequence number: 16 bits 🎀 a sequential number for the RTP packet. it ranges from 0 to 65535 and repeats itself periodically 🔁
Timestamp: 32 bits ⏰ this is a timestamp for the sampling time of the first sample of the first ATRAC frame in the current RTP packet. when using SDP, the clock rate of the RTP timestamp MUST be expressed using the "rtpmap" attribute 🫶 for ATRAC3 and ATRAC Advanced Lossless, the RTP timestamp rate MUST be 44100 Hz 🎶 for ATRAC-X, the RTP timestamp rate is 44100 Hz or 48000 Hz, and out-of-band signaling is what selects it 👑
SSRC: 32 bits 🦋 see RFC 3550 [1] 💅
CSRC list: 0 to 15 items, 32 bits each 💜 see RFC 3550 [1] 🌈
5.3. RTP Payload Structure 🧁
5.3.1. Usage of ATRAC Header Section 🌸
the ATRAC header section is one byte long, always 🫧 check out Figure 5 👀
Figure 5 🍓
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|FrgNo|NFrames|
+-+-+-+-+-+-+-+-+
Figure 5. ATRAC RTP HeaderContinuation Flag (C) : 1 bit 🔚 the packet with the last part of the audio frame data in a fragmentation MUST have this bit set to 0. otherwise, it's set to 1 ✨
Fragment Number (FrgNo): 3 bits 🎀 when data is fragmented, this value is one for the first packet, and then it goes up sequentially for the rest of the fragmented data packets 📈 this value MUST be zero for an unfragmented frame. (Note: 3 bits is enough to avoid Fragment Number rollover given the current maximum supported bit-rate in the ATRAC specification. if that changes, the choice of 3 bits for the Fragment Number should be revisited.) 🙈
Number of Frames (NFrames): 4 bits 🦋 the number of audio frames in this packet is the field value + 1 🧮 that gives a max of 16 ATRAC-encoded audio frames per packet, with 0 meaning one audio frame 💖 each audio frame MUST be complete in the packet if fragmentation is not applied. when fragmentation IS applied, only one audio frame's data is allowed to be fragmented, and this value MUST be 0 🔥
5.3.2. Usage of ATRAC Frames Section 🌈
the ATRAC Frames Section holds either an integer number of complete ATRAC frames or a single fragment of one ATRAC frame, like in Figure 6 🧚 each ATRAC frame is preceded by a one-bit flag for the layer type and a Block Length field giving the size of the ATRAC frame in bytes 💜 if there's more than one ATRAC frame, they get concatenated into a contiguous string of bit-flag, Block Length, and ATRAC frame, in order of their frame number 🫶 this section MUST NOT be empty 💅
Figure 6 🌸
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Block Length | ATRAC frame |...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. ATRAC Frame Section FormatLayer Type Flag (E): 1 bit 🍓 set to 1 if the matching ATRAC frame is from an enhancement layer. 0 means it's a base layer encoded frame 🧚
Block length: 15 bits 📏 this is the byte length of the encoded audio data for the frame that follows. it's there so that, when fragmented, decoding can still happen if only a later packet arrives 🙌 15 bits allows for a max block length of 32,767 bytes 💯
ATRAC frame: The encoded ATRAC audio data. 🎵 that's the actual audio, bestie 🎧
5.3.2.1. Support of Redundancy 🎀
okay so this payload format has a basic trick for when packets go missing 🦋 Every packet's timestamp points at its first audio frame, even when that frame is a redundant copy. We also know how many frames each packet carries. So if two packets in a row get through, we can work out how many redundant frames were sent. That tells the client how the server is reacting to RTCP reports, and it warns the client to make its buffer bigger if it needs to 💅 For an example of how redundant data gets used, check out Figures 7 and 8 ✨
in this example, the server decides that for the next few packets it should resend the last two frames from the previous packet, because of recent RTCP reports 🌸 So between packets N and N+1 there's a redundancy of two frames, and the client can choose to throw them away if it wants. The payoff comes when packets N+2 and N+3 never arrive at all. Then packet N+4 shows up with the next audio frames it needs, and it's giving resilience 🫶
[Sender]
|-Fr0-|-Fr1-|-Fr2-| Packet: N, TS=0
|-Fr1-|-Fr2-|-Fr3-| Packet: N+1, TS=1024
|-Fr2-|-Fr3-|-Fr4-| Packet: N+2, TS=2048
|-Fr3-|-Fr4-|-Fr5-| Packet: N+3, TS=3072
|-Fr4-|-Fr5-|-Fr6-| Packet: N+4, TS=4096
-----------> Packet "N+2" and "N+3" not arrived ------------->[Receiver]
|-Fr0-|-Fr1-|-Fr2-| Packet: N, TS=0
|-Fr1-|-Fr2-|-Fr3-| Packet: N+1, TS=1024
|-Fr4-|-Fr5-|-Fr6-| Packet: N+4, TS=4096the receiver can decode from Fr4 to Fr6 using the data in packet N+4, even though packets N+2 and N+3 were lost 😭🙌
Figure 7. Redundant Example 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp (= start sample time of Fr1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0 | 3 |0| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (redundant) ATRAC frame (Fr1) data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Block Length |(redundant) ATRAC frame (Fr2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |0| Block Length | ATRAC frame (Fr3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. Packet Structure Example with Redundant Data
(Case of Packet "N+1")5.3.2.2. Frame Fragmentation 🧚
okay this part is so important bestie 😭 Each RTP packet MUST contain either a whole number of ATRAC-encoded audio frames (with a maximum of 16) or one ATRAC frame fragment. When whole frames are the choice, as many complete ATRAC frames as can fit in a single path-MTU SHOULD be placed in one RTP packet. But if even one ATRAC frame won't fit in a complete RTP packet, that frame MUST be fragmented 🔥
the first piece of a fragmented frame gets its own RTP packet, with its Continuation bit (C) set to one and its Fragment Number (FragNo) set to one. That frame has to be the only thing in the packet, so the Number of Frames field is zero 🌈 The packets after that carry the rest of the fragmented frame data. Their Fragment Number goes up one step at a time, and the Continuation bit (C) stays at one. Since those later packets don't contain any new frames, the Number of Frames field MUST be ignored. The very last packet of fragmented data MUST have the Continuation bit (C) set to zero 💖
packets holding related fragmented frames MUST have identical timestamps 👑 So the Continuous bit and Fragment Number fields handle the fragmentation and the reordering, and the timestamp is how you tell which packets belong together ✨
6. Packetization Examples 🍓
6.1. Example Multi-Frame Packet
multiple encoded audio frames get squished into one packet 💅 For this example, notice that only the base layer frames are sent redundantly. They're followed by interleaved base layer and enhancement layer frames, as shown in Figure 9 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 0 | 5 |0| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (redundant) base layer frame 1 data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Block Length |(redundant) base layer frame 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |0| Block Length | base layer frame 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |1| Block Length | enhancement frame 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |0| Block Length | base layer frame 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (cont.) |1| Block Length | enhancement frame 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9. Example Multi-Frame Packet6.2. Example Fragmented ATRAC Frame
this one is a single encoded audio frame chopped up across three RTP packets 🎀 Figure 10 shows it. Look out for these two things:
- transition from one to zero of the Continuation bit (C)
- sequential increase in the Fragment Number
Packet 1:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 1 | 0 |1| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enhancement data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Packet 2:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 2 | 0 |1| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...more enhancement data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Packet 3:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 3 | 0 |1| Block Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...the last of the enhancement data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10. Example Fragmented ATRAC Frame7. Payload Format Parameters ✨
okay so certain parameters have to be defined before ATRAC-family-encoded content can be streamed 🫶 Other optional parameters can also be defined, to make use of features that matter for particular ATRAC versions. The parameters for ATRAC3, ATRAC-X, and ATRAC Advanced Lossless are defined here as part of the media subtype registration process 🌸 There's also a mapping of these parameters into the Session Description Protocol (SDP) (RFC 4566) [2] for apps that use SDP. These registrations use the template defined in RFC 4288 [5] and follow RFC 4855 [6] 💜
the data format and parameters are specified for real-time transport in RTP 🦋
7.1. ATRAC3 Media Type Registration 🎀
Okay bestie, this is the ATRAC3 registration 💖 The subtype uses the template from RFC 4855 [6], so nobody has to reinvent the wheel 🧚
Note, any unknown parameter MUST be ignored by the receiver. 🙈 If a receiver doesn't recognise a parameter, it just skips it.
- Type name:
audio - Subtype name:
ATRAC3
Required parameters:
rate: the sampling frequency in Hz of the original audio data. Only44100is allowed, so no other rates, no cap 🙅♀️baseLayer: the encoded bit-rate in kbps for the audio being streamed. The allowed values are66,105, and132🍓
Optional parameters:
ptime: see RFC 4566 [2].maxptime: see RFC 4566 [2]. Here's the lowkey math moment ✨ An ATRAC3 frame is 1024/44100 = 23.22...(ms), and fractions may not even be applicable in SDP. So the value of this parameter MUST be a multiple of 24 (ms) for safe transmission 💅
If this parameter is not present, the sender MAY pack a maximum of 6 encoded frames into one RTP packet while streaming ATRAC3. 🦋
maxRedundantFrames: the maximum number of redundant frames that may be sent during a session in any given packet, under the redundant framing mechanism detailed in the document. Allowed values are integers from 0 to 15, inclusive. If this parameter is not used, a default of 15 MUST be assumed 👑- Encoding considerations: This media type is framed and contains binary data.
- Security considerations: This media type does not carry active content. See Section 9 of this document. Dramatic? Yes. Important? Also yes 😭
- Interoperability considerations: none
- Published specification: ATRAC3 Standard Specification [9]
- Applications that use this media type: Audio and video streaming and conferencing tools.
- Additional information: none
- Magic number(s): none
- File extension(s):
at3,aa3, andomg - Macintosh file type code(s): none
- Person and email address to contact for further information: Mitsuyuki Hatanaka, Jun Matsumoto, actech@jp.sony.com
- Intended usage: COMMON
- Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP. No RTP, no ATRAC3 🫶
- Author: Mitsuyuki Hatanaka, Jun Matsumoto, actech@jp.sony.com
- Change controller: IETF AVT WG delegated from the IESG
7.2. ATRAC-X Media Type Registration 🌸
Now for ATRAC-X, the same vibe with a few extra knobs 🎛️ It uses the template from RFC 4855 [6] too.
Note, any unknown parameter MUST be ignored by the receiver. Same energy as before: unknown stuff gets skipped 💜
- Type name:
audio - Subtype name:
ATRAC-X
Required parameters:
rate: the sampling frequency in Hz of the original audio data. The permissible values are44100and48000🌈baseLayer: the encoded bit-rate in kbps for the audio being streamed. The permissible values are32,48,64,96,128,160,192,256,320, and352🍰channelID: indicates the number of channels and the channel layout, according to the table1 in Section 7.4. Heads up, this layout is different from the one proposed in RFC 3551 [3] 👀 However, sincechannelID=0defines an ambiguous channel layout, the channel mapping defined in Section 4.1 of [3] could be used instead. The permissible values are0,1,2,3,4,5,6, and7✨
Optional parameters:
ptime: see RFC 4566 [2].maxptime: see RFC 4566 [2]. The frame length of ATRAC-X is 2048/44100 = 46.44...(ms) or 2048/48000 = 42.67...(ms), but fractions may not be applicable for SDP. So the value of this parameter MUST be a multiple of 47 (ms) or 43 (ms) for safe transmission 🧮
If this parameter is not present, the sender MAY pack a maximum of 16 encoded frames into one RTP packet while streaming ATRAC-X. 🦋
maxRedundantFrames: the maximum number of redundant frames that may be sent during a session in any given packet, under the redundant framing mechanism detailed in the document. Allowed values are integers from 0 to 15, inclusive. If this parameter is not used, a default of 15 MUST be assumed 👑delayMode: indicates a desire to use low-delay features, in which case the decoder will process received data accordingly based on this value. The permissible values are2and4⚡- Encoding considerations: This media type is framed and contains binary data.
- Security considerations: This media type does not carry active content. See Section 9 of this document. Still serious, still dramatic 🙈
- Interoperability considerations: none
- Published specification: ATRAC-X Standard Specification [10]
- Applications that use this media type: Audio and video streaming and conferencing tools.
- Additional information: none
- Magic number(s): none
- File extension(s):
atx,aa3, andomg - Macintosh file type code(s): none
- Person and email address to contact for further information: Mitsuyuki Hatanaka, Jun Matsumoto, actech@jp.sony.com
- Intended usage: COMMON
- Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP. 💅
- Author: Mitsuyuki Hatanaka, Jun Matsumoto, actech@jp.sony.com
- Change controller: IETF AVT WG delegated from the IESG
7.3. ATRAC Advanced Lossless Media Type Registration 🦄
This one is the big boss of the ATRAC family 👑 The media subtype for the Adaptive TRansform Codec Lossless version (ATRAC Advanced Lossless) uses the template from RFC 4855 [6].
Note, any unknown parameter MUST be ignored by the receiver. Consistent as always 🫶
- Type name:
audio - Subtype name:
ATRAC-ADVANCED-LOSSLESS
Required parameters:
rate: the sampling frequency in Hz of the original audio data. In High-Speed Transfer mode, the only permissible value is44100. For Standard mode, any of24000,32000,44100,48000,64000,88200,96000,176400, and192000can be used 🌊baseLayer: the encoded bit-rate in kbps for the base layer in High-Speed Transfer mode lossless encodings. For Standard lossless mode, this value MUST be0. Otherwise, the permissible ATRAC3 base layer values are66,105, and132, and the permissible ATRAC-X base layer values are32,48,64,96,128,160,192,256,320, and352📚blockLength: the block length. In High-Speed Transfer mode,1024and2048are used for ATRAC3-based and ATRAC-X-based ATRAC Advanced Lossless streaming, respectively. For Standard mode, any of512,1024, and2048can be used 🧱channelID: indicates the number of channels and the channel layout, according to the table1 in Section 7.4. The layout is different from the one proposed in RFC 3551 [3], so note that 👀 AschannelID=0defines an ambiguous channel layout, the channel mapping defined in Section 4.1 of [3] could be used in this case. The permissible values are0,1,2,3,4,5,6, and7✨
Optional parameters:
ptime: see RFC 4566 [2].maxptime: see RFC 4566 [2]. Here's the tea ☕ When streaming ATRAC Advanced Lossless, multiple frames cannot be sent in a single RTP packet, because the frame size is large. So it SHOULD be regarded as the time of one encoded frame on both the sender and the receiver side. The frame length of ATRAC Advanced Lossless is 512/44100 = 11.6...(ms), 1024/44100 = 23.22...(ms), or 2048/44100 = 46.44...(ms), but fractions may not be applicable for SDP. So the value of this parameter MUST be 12(ms), 24(ms), or 47(ms) for safe transmission 🧠- Encoding considerations: This media type is framed and contains binary data.
- Security considerations: This media type does not carry active content. See Section 9 of this document. Yes, we're still doing the serious face 😭
- Interoperability considerations: none
- Published specification: ATRAC Advanced Lossless Standard Specification [11]
- Applications that use this media type: Audio and video streaming and conferencing tools.
- Additional information: none
- Magic number(s): none
- File extension(s):
aal,aa3, andomg - Macintosh file type code(s): none
- Person and email address to contact for further information: Mitsuyuki Hatanaka, Jun Matsumoto, actech@jp.sony.com
- Intended usage: COMMON
- Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP. 🎀
- Author: Mitsuyuki Hatanaka, Jun Matsumoto, actech@jp.sony.com
- Change controller: IETF AVT WG delegated from the IESG
7.4. Channel Mapping Configuration Table 🗺️
Table 1 explains the mapping between the channelID passed during SDP negotiations and the speaker mapping that value represents. Here's the whole thing, verbatim 💖
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| channelID | Number of | Default Speaker |
| | Channels | Mapping |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | max 64 | undefined |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 1 | front: center |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 2 | front: left, right |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | front: left, right |
| | | front: center |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 4 | front: left, right |
| | | front: center |
| | | rear: surround |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 5+1 | front: left, right |
| | | front: center |
| | | rear: left, right |
| | | LFE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 6+1 | front: left, right |
| | | front: center |
| | | rear: left, right |
| | | rear: center |
| | | LFE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 7+1 | front: left, right |
| | | front: center |
| | | rear: left, right |
| | | side: left, right |
| | | LFE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 1. Channel Configuration7.5. Mapping Media Type Parameters into SDP 🪄
The info in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [2], which is what most people use to describe RTP sessions. When SDP is used to specify sessions that employ the ATRAC family of codecs, the following mapping rules for the ATRAC codec apply. It's giving organisation 📋
7.5.1. For Media Subtype ATRAC3
- The media type (
audio) goes in SDPm=as the media name. - The media subtype (payload format name) goes in SDP
a=rtpmapas the encoding name. ATRAC3 supports only mono or stereo signals, so a corresponding number of channels (0 or 1) MUST also be specified in this attribute 🎧 - The
baseLayerparameter goes in SDPa=fmtp. This parameter MUST be present.maxRedundantFramesmay follow, but if no value is transmitted, the receiver SHOULD assume a default value of15💜 - The parameters
ptimeandmaxptimego in the SDPa=ptimeanda=maxptimeattributes, respectively. ✨
7.5.2. For Media Subtype ATRAC-X 💖
- okay so the media type ("audio") goes in the SDP "m=" line as the media name 🎀
- the media subtype (aka the payload format name) goes in "a=rtpmap" as the encoding name. This SHOULD be followed by the "sampleRate" (that's your RTP clock rate 🦋), and then the actual number of channels, no matter what channelID says ✨
- "ptime" and "maxptime" go in the "a=ptime" and "a=maxptime" attributes, respectively 💅
- any leftover parameters go in the "a=fmtp" attribute, copied straight from the Media type string as a semicolon-separated list of parameter=value pairs. "baseLayer" MUST be the very first entry on that line, and "channelID" MUST be the next one. The receiver MUST assume a default value of "15" for "maxRedundantFrames" 🫶
7.5.3. For Media Subtype ATRAC Advanced Lossless 🌈
- the Media type ("audio") goes in SDP "m=" as the media name 🎀
- the media subtype (payload format name) goes in "a=rtpmap" as the encoding name. This MUST be followed by the "sampleRate" (as the RTP clock rate), and then the actual number of channels, regardless of channelID 🦋
- "ptime" and "maxptime" go in "a=ptime" and "a=maxptime" ✨
- remaining parameters go in "a=fmtp", copied directly from the Media type string as a semicolon-separated list of parameter=value pairs.
okay so on this line, "baseLayer" and "blockLength" MUST be present, in that order 👑
the "blockLength" value MUST be 1024 or 2048 when you're using ATRAC3 or ATRAC-X as the baselayer, respectively. If "baseLayer=0" (that's standard mode), "blockLength" MUST be one of 512, 1024, or 2048. "channelID" MUST be the next entry. The receiver MUST assume a default value of "15" for "maxRedundantFrames" 🧚
7.6. Offer/Answer Model Considerations 🤝
Some ways of encoding and decoding ATRAC audio data need the sender, the receiver, or both to follow certain specs. To get an interoperable transmission setup, an Offer/Answer negotiation in SDP MUST observe the considerations below. (See [14].) 💜
7.6.1. For All Three Media Subtypes 🍓
- each combo of the RTP payload transport format configuration parameters (baseLayer and blockLength, sampleRate, channelID) has its own unique bit-pattern and is not compatible with any other combo. When an offerer wants the fancier stuff (sample rates above 44100 kHz, more than two channels), they SHOULD also offer a payload type with only the lowest set of necessary requirements. If the application cares about several configurations, it may offer all of them 💅
- "maxptime" and "ptime" usually won't affect interoperability, but the settings can still change how well the application performs 🔥. The SDP Offer/Answer handling of "ptime" is described in RFC 3264, and "maxptime" MUST be handled in exactly the same way ✨
7.6.2. For Media Subtype ATRAC3 🦋
- in response to an offer, downgraded subsets of "baseLayer" are possible. For the best performance, though, we suggest the answer contain the highest values that were offered 👑
7.6.3. For Media Subtype ATRAC-X 🎀
- in response to an offer, downgraded subsets of "sampleRate", "baseLayer", and "channelID" are possible. For the best performance, an answer MUST NOT contain any values that need more capabilities than the offer has, but it SHOULD give values as close as possible to the ones in the offer 💖
- "maxRedundantFrames" is a suggested minimum. An answer MAY raise this value (max of 15), but it MUST NOT be lowered 🧚
- the optional parameter "delayMode" is non-negotiable. If the Answerer can't comply with the offered value, the session MUST be deemed inoperable 😭
7.6.4. For Media Subtype ATRAC Advanced Lossless 🌸
- in response to an offer, downgraded subsets of "sampleRate", "baseLayer", and "channelID" are possible. For the best performance, an answer MUST NOT contain any values that need more capabilities than the offer has, but it SHOULD give values as close as possible to the ones in the offer 💅
- there are no requirements when negotiating "blockLength", other than that both parties have to agree 🫶
- "maxRedundantFrames" is a suggested minimum. An answer MAY raise this value (max of 15), but it MUST NOT be lowered 🌈
- for scalable multi-session streaming of ATRAC Advanced Lossless content, the media stream identification, group info, and decoding dependency between the base layer stream and the enhancement layer stream MUST be signaled in SDP through the Offer/Answer model. In this case, the "group", "mid", and "depend" attributes, each followed by the appropriate parameter, MUST be used in SDP [7] [8] to show the layered coding dependency. The "group" attribute followed by the "DDP" parameter shows the relationship between the base and enhancement layer streams that have a decoding dependency. Each stream is identified by its "mid" attribute, and the enhancement layer's dependency is defined by the "depend" attribute, since the enhancement layer is only useful when the base layer is available 🧠. Examples of signaling ATRAC Advanced Lossless decoding dependency are in Sections 7.8 and 7.9 🦋
7.7. Usage of Declarative SDP 📜
In declarative usage, like SDP in Real-Time Streaming Protocol (RTSP) [15] or Session Announcement Protocol (SAP) [16], the parameters MUST be interpreted as follows: 👑
- the payload format configuration parameters (baseLayer, sampleRate, channelID) are all declarative, and a participant MUST use the configuration(s) given for the session. You can declare more than one configuration if you really need to, by declaring multiple RTP payload types, but the number of types SHOULD be kept small 🎀
- any "maxptime" and "ptime" values SHOULD be picked with care so the session's participants can get reasonable performance 💖
- the "mid", "group", and "depend" attributes MUST be used to show the relationship and dependency between the base layer and the enhancement layer in scalable multi-session streaming of ATRAC ADVANCED LOSSLESS content, as described in Sections 7.6, 7.8, and 7.9 ✨
7.8. Example SDP Session Descriptions 🎬
Here's ATRAC-X with stereo at 44100 Hz 🎧
v=0
o=atrac 2465317890 2465317890 IN IP4 service.example.com
s=ATRAC-X Streaming
c=IN IP4 192.0.2.1/127
t=3409539540 3409543140
m=audio 49120 RTP/AVP 99
a=rtpmap:99 ATRAC-X/44100/2
a=fmtp:99 baseLayer=128; channelID=2; delayMode=2
a=maxptime:47Here's ATRAC-X with a 5.1 setup at 48000 Hz 🔊
v=0
o=atrac 2465317890 2465317890 IN IP4 service.example.com
s=ATRAC-X 5.1ch Streaming
c=IN IP4 192.0.2.1/127
t=3409539540 3409543140
m=audio 49120 RTP/AVP 99
a=rtpmap:99 ATRAC-X/48000/6
a=fmtp:99 baseLayer=320; channelID=5
a=maxptime:43Here's ATRAC-Advanced-Lossless in multiplexed High-Speed Transfer mode 🚀
v=0
o=atrac 2465317890 2465317890 IN IP4 service.example.com
s=AAL Multiplexed Streaming
c=IN IP4 192.0.2.1/127
t=3409539540 3409543140
m=audio 49200 RTP/AVP 96
a=rtpmap:96 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:96 baseLayer=128; blockLength=2048; channelID=2
a=maxptime:47Here's ATRAC-Advanced-Lossless in multi-session High-Speed Transfer mode 🌟 In this one, the base layer and the enhancement layer are identified as L1 and L2, and L2 depends on L1 when decoding 🧩
v=0
o=atrac 2465317890 2465317890 IN IP4 service.example.com
s=AAL Multi Session Streaming
c=IN IP4 192.0.2.1/127
t=3409539540 3409543140
a=group:DDP L1 L2
m=audio 49200 RTP/AVP 96
a=rtpmap:96 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:96 baseLayer=128; blockLength=2048; channelID=2
a=maxptime:47
a=mid:L1
m=audio 49202 RTP/AVP 97
a=rtpmap:97 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:97 baseLayer=0; blockLength=2048; channelID=2
a=maxptime:47
a=mid:L2
a=depend:97 lay L1:96Here's ATRAC-Advanced-Lossless in Standard mode 🙈
m=audio 49200 RTP/AVP 99
a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:99 baseLayer=0; blockLength=1024; channelID=2
a=maxptime:247.9. Example Offer/Answer Exchange 🫧
First up, a multi-channel offer gets turned down by the receiver, who answers with only stereo support 🙅♀️
Offer:
m=audio 49170 RTP/AVP 98 99
a=rtpmap:98 ATRAC-X/44100/6
a=fmtp:98 baseLayer=320; channelID=5
a=rtpmap:99 ATRAC-X/44100/2
a=fmtp:99 baseLayer=160; channelID=2Answer:
m=audio 49170 RTP/AVP 99
a=rtpmap:99 ATRAC-X/44100/2
a=fmtp:99 baseLayer=160; channelID=2Next, the receiver answers with a selection of the parameters it supports 🎯
Offer:
m=audio 49170 RTP/AVP 97 98 99
a=rtpmap:97 ATRAC-X/44100/2
a=fmtp:97 baseLayer=128; channelID=2
a=rtpmap:98 ATRAC-X/44100/6
a=fmtp:98 baseLayer=128; channelID=5
a=rtpmap:99 ATRAC-X/48000/6
a=fmtp:99 baseLayer=320; channelID=5Answer:
m=audio 49170 RTP/AVP 97 98
a=rtpmap:97 ATRAC-X/44100/2
a=fmtp:97 baseLayer=128; channelID=2
a=rtpmap:98 ATRAC-X/44100/6
a=fmtp:98 baseLayer=128; channelID=5Then there's an exchange trying to sort out ATRAC-Advanced-Lossless 🧐 The offer has three options: multi-session High-Speed Transfer mode, multiplexed High-Speed Transfer mode, and Standard mode 🌈
Offer:
// Multi-session High-Speed Transfer mode, L1 and L2 correspond
to the base layer and the enhancement layer, respectively, and L2
depends on L1 in decoding.
a=group:DDP L1 L2
m=audio 49200 RTP/AVP 96
a=rtpmap:96 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:96 baseLayer=132; blockLength=1024; channelID=2
a=maxptime:24
a=mid:L1
m=audio 49202 RTP/AVP 97
a=rtpmap:97 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:97 baseLayer=0; blockLength=2048; channelID=2
a=maxptime:24
a=mid:L2
a=depend:97 lay L1:96
// Multiplexed High-Speed Transfer mode
m=audio 49200 RTP/AVP 98
a=rtpmap:98 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:98 baseLayer=256; blockLength=2048; channelID=2
a=maxptime:47
// Standard mode
m=audio 49200 RTP/AVP 99
a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:99 baseLayer=0; blockLength=2048; channelID=2
a=maxptime:47Answer:
a=group:DDP L1 L2
m=audio 49200 RTP/AVP 94
a=rtpmap:94 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:94 baseLayer=132; blockLength=1024; channelID=2
a=maxptime:24
a=mid:L1
m=audio 49202 RTP/AVP 95
a=rtpmap:95 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:95 baseLayer=0; blockLength=2048; channelID=2
a=maxptime:24
a=mid:L2
a=depend:95 lay L1:94Quick note 📝 the names of payload formats (encodings) and Media subtypes are case-insensitive in both places, and parameter names are case-insensitive too, both in Media types and in the default mapping to the SDP a=fmtp attribute 💜
8. IANA Considerations ✨
okay so IANA bestie 🎀 three brand new Media subtypes officially got registered: audio/ATRAC3, audio/ATRAC-X, and audio/ATRAC-ADVANCED-LOSSLESS 🦋 (see Section 7). the whole ATRAC lineup is in the registry now 💅
9. Security Considerations 🔐
okay this part is SERIOUS bestie, so read closely 👀 the payload format in this doc is subject to the security considerations in RFC 3550 [1] and any applicable profile, like RFC 3551 [3]. also, the security of Media type registration MUST be taken into account, as described in Section 5 of RFC 4855 [6] 🫶
the ATRAC payload is only compressed audio data that gets decoded and played as sound 🎧 the standard specs for ATRAC3, ATRAC-X, and ATRAC Advanced Lossless [9] [10] [11] strictly define the bit stream syntax and the decoder-side buffer model for each codec. so it can not carry "active content" that could cause malicious side effects on the receiver 🙅♀️ and it does not cause any problem of illegal resource consumption on the receiver side, as long as the bit streams conform to their standard specifications 🌸
⚠️ this payload format does NOT implement any security mechanisms of its own. confidentiality, integrity protection, and authentication have to be provided by a mechanism outside this payload format, e.g., SRTP RFC 3711 [13]. no shortcuts here, bestie 💜
10. Considerations on Correct Decoding 🧠
10.1. Verification of the Packets
verifying the received encoded audio packets MUST be performed so the packets get decoded correctly 🔍 as a most primitive implementation, comparing the packet size and payload length can be taken into account ✨ if the UDP packet is longer than the RTP packet, the packet can be accepted, but the extra bytes MUST be ignored 🦋 if you receive a shorter UDP packet or improperly encoded packets, those packets MUST be discarded 🗑️
10.2. Validity Checking of the Packets
also, validity checking of the received audio packets MUST be performed 💅 it can be done by the decoding process, because the ATRAC format is designed so that the validity of data frames can be determined by decoding 🧚 the required decoder response to a malformed frame is to discard the malformed data and conceal the errors in the audio output until a valid frame is detected and decoded. this is expected to prevent crashes and other abnormal decoder behavior in response to errors or attacks 🛡️✨
11. References 📚
11.1. Normative References
- [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
- [3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [5] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
- [6] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
- [7] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
- [8] Schierl, T., and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, July 2009.
- [9] ATRAC3 Standard Specification ver.1.1, Sony Corporation, 2003.
- [10] ATRAC-X Standard Specification ver.1.2, Sony Corporation, 2004.
- [11] ATRAC Advanced Lossless Standard Specification ver.1.1, Sony Corporation, 2007.
11.2. Informative References
- [12] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
- [13] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
- [14] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
- [15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
- [16] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
Authors' Addresses 💌
Mitsuyuki Hatanaka
Sony Corporation, Japan
1-7-1 Konan
Minato-ku
Tokyo 108-0075
Japan
EMail: actech@jp.sony.com
Jun Matsumoto
Sony Corporation, Japan
1-7-1 Konan
Minato-ku
Tokyo 108-0075
Japan
EMail: actech@jp.sony.comthat's the whole spec, bestie!! 🌈💖 ATRAC got its moment and the authors are super easy to find ✨
📦 where this page comes from
- ietf: rfc5584 2009-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms