Atrium — a native tvOS app for your Emby server

[vdatanet 1659]

Hi all,

I've been building Atrium, a native tvOS app for home media servers, and as of version 1.2 it
works with Emby. It's on the App Store, it's free, and it stays free: no in-app purchases, no
subscription, no ads, no tracking, and no Atrium account — you point it at your own server, sign in
with your own user, and that's it. (It speaks to Jellyfin servers too; the app doesn't ask you
which, it works it out when you connect.)

Some of you may remember me from topic 149003, where I asked about the HLS manifest a few weeks
ago. That thread is the reason this post has one caveat, and I'd rather lead with it than have
anyone find it on their TV.

--- With Emby, HDR video is tone-mapped to SDR ---

Here is why, as precisely as I can put it.

On Apple platforms the player decides the display mode from the multivariant playlist *before* it
downloads a single segment. It reads the attributes on #EXT-X-STREAM-INF — VIDEO-RANGE, CODECS —
to work out what the stream is and to configure the display. Emby's transcoding manifest currently
carries neither, so tvOS has nothing to act on and never switches the TV into HDR mode.

The bytes are fine, and I checked: I pulled the #EXT-X-MAP init segment and the first media
segment, concatenated them and ran ffprobe. It comes back smpte2084 (PQ) with BT.2020 primaries —
real HDR, being sent right now.

But an app can't use that. If it just plays the stream, the display stays in SDR, and PQ content
shown on an SDR display looks washed out — worse than not trying. So Atrium does the honest thing
instead: it tells the server it accepts SDR, the server tone-maps, and what you see is correct.
Less than the file holds, but right.

One thing that makes this cheaper than it sounds: the transcode currently comes out 8-bit
(yuv420p) even when the command line asks for main10, and PQ at 8 bits bands visibly. So what is
actually being given up is smaller than "no HDR" makes it sound.

--- What would change it ---

Populating VIDEO-RANGE and CODECS on #EXT-X-STREAM-INF (and SUPPLEMENTAL-CODECS where Dolby Vision
applies), reflecting what the stream really is. That's the whole ask — it isn't a change to what
the transcoder produces, only to how it's described.

On my side the HDR path is already written and shipping; asking for HDR again instead of SDR is a
one-line change and a release. I'd be glad to test any build against a 4K HDR/DV library and report
back with player-side measurements: which variant is chosen, what the player reports the range as,
and whether the display actually switches.

--- Everything else ---

Libraries, search, Continue Watching, the Apple TV top shelf, subtitles through the native tvOS
picker, music with a proper queue. If something doesn't work the way you expect, I'd genuinely
like to hear about it — this is the first release Emby users have had their hands on, and you'll
find things I can't.

https://apps.apple.com/app/atrium-media-player/id6777638751

Thanks — and thanks for the pointers in the earlier thread, they're what got the measurements
right.

Edited 2 hours ago by vdatanet

[alex77777 51]

@vdatanetSo just to clarify, currently your app only displays SDR at the moment? 

I'm testing it out and honestly its a really smooth experience. Do you plan on having it direct play formats like DTS-HD MA and TrueHD to the Apple TV similar to how Infuse does it?

[vdatanet 1659]

No — the app does HDR10, HLG and Dolby Vision, and against other server types it already switches an Apple TV 4K into HDR correctly. What you're seeing as SDR is Emby's side of the HLS path, and I've measured it fairly carefully.

Emby's #EXT-X-STREAM-INF carries no VIDEO-RANGE attribute and no CODECS attribute. On Apple platforms the player decides what a stream is before it downloads a single segment — it reads those attributes both to rule variants in or out and to pre-configure the display — so with neither present, Match Dynamic Range never fires and the TV stays in SDR. The segments themselves are fine: I pulled the #EXT-X-MAP init segment plus the first media segment and ran ffprobe, once on an HDR10 title and once on a Dolby Vision one, and both come back smpte2084 / bt2020. Emby is sending me HDR right now; it just doesn't say so in the manifest, and by the time the player has a segment in hand it's too late. Full write-up and measurements are in this thread. If those attributes get populated, HDR works here with no change on my side.

On the audio: no, and that's a deliberate limit rather than something waiting on the roadmap. The app is built on AVPlayer/AVFoundation only — no bundled software decoder. That's the whole bet: hardware decoding, Match Dynamic Range and Match Frame Rate, the system transport UI, tvOS's own subtitle rendering. The price is that I'm bound by what AVFoundation accepts, and it doesn't decode or bitstream TrueHD or DTS in any form. Infuse ships its own player engine, which is how it can bitstream those to a receiver; doing the same would mean giving up everything above, and I'd rather push the native player as far as it goes.

In practice that means AAC, AC-3, E-AC-3, ALAC, FLAC and LPCM direct play untouched — including Dolby Atmos when it's carried in E-AC-3 (JOC), which is the form the Apple TV supports natively anyway. A TrueHD or DTS-HD MA track gets transcoded server-side, audio only, with the video still copied: you lose the lossless track, and TrueHD Atmos comes down to a channel bed. Most 4K remuxes carry a DD+ or AC-3 compatibility track alongside the lossless one — picking that in the audio menu direct plays, and keeps Atmos if it's there.

Glad the rest feels smooth — thanks for putting it through its paces.

[vdatanet 1659]

A correction to my own post, and it goes in Emby's favour, so I'd rather put it up than leave it
standing.

I wrote that Emby was sending real HDR and simply not describing it in the manifest, and that the
transcode came out 8-bit with visible banding. Both of those are wrong. I re-ran the same
measurement today against the same Emby version, and what arrives is a proper tone-map to Rec. 709
— on the HDR10 title and on the Dolby Vision one alike. The manifest carries no HDR label because
there is no HDR to label. That is Emby doing the correct thing.

What I had actually caught was a fault on my own server: tone-mapping was failing there in a way
that left the HDR tags attached to a picture that was no longer HDR, and I read the tags rather than
the picture. The same Emby build handles it correctly now, so that was my machine and not the
server.

What doesn't change is the limitation I posted about. With Emby, Atrium still shows SDR, for the
same reason as before: the manifest doesn't describe the dynamic range, so tvOS never switches the
TV into HDR mode, and asking for HDR anyway would only mean HDR content on a display that stays in
SDR. Asking for SDR is the honest option, and it's what the app does.

For anyone who wants the actual measurements, that side of it belongs in the developer section — I'm
posting the details in topic 149003.