# Dolby Atmos and TrueHD on Apple TV
> Tomo TV plays Dolby Atmos on Apple TV by copying Dolby Digital Plus untouched, so the object data reaches the receiver. A 7.1 Blu-ray track needed one more step: its Atmos flag sits in a dependent frame the MP4 muxer never read, so the player saw plain multichannel. TrueHD and DTS-HD decode to lossless FLAC and keep every channel.
- ID: LAB-015
- Area: Playback engine ยท Dolby audio
- Problem: Dolby Atmos rides inside Dolby Digital Plus as object data. Decode the stream, or misread its header, and the receiver never sees the objects.
- Solution: AC-3 and E-AC-3 copy byte for byte, the muxer reads the Atmos flag from the frame that carries it, and TrueHD and DTS decode to lossless FLAC.
- Status: Shipped in 2.2.12
- Published: 2026-10-05
- Updated: 2026-10-17
- Author: Keiver Hernandez
- URL: https://keiver.dev/lab/dolby-atmos-truehd-apple-tv
- Source: https://github.com/keiver/tomotv
Dolby Atmos on Apple TV looks like one feature and is two problems. Atmos rides inside Dolby Digital Plus (E-AC-3) as object data, and a client that decodes that stream hands the receiver plain multichannel sound. TrueHD carries Atmos too, but no Apple device accepts a TrueHD bitstream, so it takes another road. Tomo TV handles both with one short decision and a header fix that a 7.1 Blu-ray track forced on us.
## Dolby Atmos on Apple TV survives only as a copied bitstream
AC-3 and E-AC-3 are the only audio formats Apple TV passes to the receiver still compressed. For Dolby Digital Plus with Atmos that is the whole game. The object data, the position of each sound, lives inside that bitstream. Decode it and the receiver gets multichannel PCM with the objects gone.
The engine's decision is a short codec switch. AAC, ALAC, AC-3 and E-AC-3 copy. FLAC copies when its header is a plain STREAMINFO block. Everything else goes through the decoder.
[packages/tomo-engine/ios/LocalRemuxer/AudioTranscoder.swift:152-159](https://github.com/keiver/tomotv/blob/46bfa54d58464cf2c88f5975c8be72e120ab8fa0/packages/tomo-engine/ios/LocalRemuxer/AudioTranscoder.swift#L152-L159)
```swift
switch params.pointee.codec_id {
case AV_CODEC_ID_AAC, AV_CODEC_ID_ALAC, AV_CODEC_ID_AC3, AV_CODEC_ID_EAC3:
return false
case AV_CODEC_ID_FLAC:
return params.pointee.extradata_size != FLAC_STREAMINFO_SIZE
default:
return true
}
```
Getting a copied E-AC-3 track into an HLS segment needs one more step. The MP4 muxer builds the track header from a real packet, so the engine defers that header with FFmpeg's `delay_moov` option and treats the muxer's first flush as the init segment. An earlier attempt stopped at that first flush, saw a fragment AVPlayer rejects, and shelved passthrough on one reading when the second flush was the clean one.
The playback suite checks the engine's output for a fixture with genuine Atmos data and expects the profile "Dolby Digital Plus + Dolby Atmos". That proves the objects survive in the packets. It does not prove the player is told about them, which is the 7.1 story.
## Dolby Digital Plus 7.1 Atmos: the flag the muxer never read
A UHD disc remux carried two Dolby Digital Plus Atmos tracks, a 5.1 and a 7.1. The 5.1 showed the Dolby Atmos badge. The 7.1 played as plain multichannel. The bytes were copied untouched both times, so the difference had to be in what the player was told.
Dolby Atmos is object audio. A bed of sounds is fixed to speakers, and objects with positions are rendered to whatever speakers the room has. Inside Dolby Digital Plus it travels as Joint Object Coding (JOC): the mix is folded down to 5.1 and coded as ordinary E-AC-3, with side data that lets the decoder rebuild the objects. A flag in the frame announces that extension, and the MP4 sample entry (the `dec3` box) carries the same flag.
The 5.1 track used the streaming layout: one E-AC-3 frame per packet, flag inside it. That is the form Apple's HLS specification lists as Dolby Digital Plus JOC.
The 7.1 track used the Blu-ray layout, where each packet holds two frames. First comes a Dolby Digital 5.1 core that any decoder can play. Then comes a dependent Dolby Digital Plus frame with two height channels and the object data, so "7.1" here means eight channels, not seven on the floor. Dolby's specification puts the flag in that last frame on purpose.
FFmpeg's MP4 muxer reads the flag from the first frame of each packet, where the streaming layout keeps it. It walks the dependent frames only for their channel counts. For the Blu-ray layout the `dec3` box said no Atmos, and the player believed the box. Tomo TV's FFmpeg build takes the flag from the dependent frame when there is one. The box grew from 6 bytes to 8, and the 7.1 track lights the badge.
The lesson: copying the bytes kept the objects, and the player still could not see them, because a player reads the header before the frames. Our suite read the frames, so it passed on this layout all along. A test that proves the data survived must also read what the header declares.
## TrueHD on Apple TV decodes to lossless FLAC
TrueHD and DTS-HD Master Audio are Blu-ray formats. A disc player sends them to the receiver as a bitstream over HDMI, objects and all. Apple TV never does that: the only compressed audio it passes through is AC-3 and E-AC-3, and everything else leaves the box as PCM. AVPlayer has no decoder for TrueHD or DTS either, so a copied track would be silent.
The engine decodes them itself, and the Atmos and DTS:X objects do not survive that decode. What survives is every channel, and we keep them whole by encoding to FLAC rather than AAC. FLAC is lossless, so the decoded audio reaches the player bit for bit.
## The AirPods Dolby Atmos badge counts only when it shows
With AirPods, Control Center on Apple TV shows a Dolby Atmos heading during playback. When it shows, Atmos is there. When it does not, you have learned nothing yet. The JOC marker only surfaces once a decoder has parsed enough frames, and at FFmpeg's default probe depth the profile reads empty. Atmos then looks lost when it is merely unread.
Each codec's path through the engine:
```mermaid
flowchart LR
A["AC-3 / E-AC-3
Dolby"] --> CP[Copy]
B["AAC / ALAC / FLAC"] --> CP
C["TrueHD / DTS / DTS-HD"] --> TR[Decode]
D["MP3 / Opus / PCM / ..."] --> TR
TR --> FL["FLAC
lossless"]
CP --> PL[AVPlayer]
FL --> PL
```
---
The rule that transfers: keep the copy set small and give each member a reason. AC-3 and E-AC-3 copy because Apple receivers consume them directly and the Atmos data survives. AAC and ALAC copy because AVPlayer already handles them. A lossless codec the muxer cannot accept earns a path through the encoder, not an exception. And when a copy looks right in the frames, read the header too. The picture side of the same disc rips is in [Dolby Vision Profile 7 on Apple TV](/lab/dolby-vision-profile-7-apple-tv). When the server steps in at all is in [when should a Jellyfin client transcode?](/lab/when-should-a-jellyfin-client-transcode), and the app is at [Tomo TV](/lab/tomotv).
Dolby, Dolby Atmos and Dolby Digital Plus are trademarks of Dolby Laboratories Licensing Corporation. The JOC details above follow Dolby's public specification, ETSI TS 103 420. Apple TV and AirPods are trademarks of Apple Inc. FFmpeg is free software that Tomo TV uses under the LGPL. The build script and its source patch are published in the Tomo TV repository.
Drafted with Claude from Tomo TV's code and device measurements. Reviewed, edited and verified by Keiver Hernandez.
Cite as: Keiver Hernandez, "Dolby Atmos and TrueHD on Apple TV", keiver.dev/lab/dolby-atmos-truehd-apple-tv, 2026-10-05.