[Feature Request] Add support for MKV HEVC HDR playback using Apple TV (without tone mapping)

[Neminem 1737]

15 minutes ago, zaHrecsohbiw said:

fMP4

What is this format ?

[vdatanet 1623]

1 minute ago, Neminem said:

What is this format ?

https://hlsbook.net/hls-fragmented-mp4/

[Neminem 1737]

@vdatanetThank you for educating me

I was wondering

[steven_pilch 5]

Plus 10000 for this.

[vdatanet 1623]

 

I wanted to share something I've been experimenting with, in case it's useful for this request.

It turns out that delivering the video over HLS with fMP4 (fragmented MP4) segments opens up a really nice path for these MKV HEVC HDR files on the Apple TV. Rather than transcoding (and tone-mapping) the video, the server can simply remux the MKV into fMP4 over HLS and stream-copy the HEVC video untouched — it's essentially just a container rewrite, so it's very light on the server and, importantly, it keeps the HDR intact.

Here's the result on an Apple TV 4K, playing a 4K HEVC Dolby Vision (Profile 8.1) title: (Jellyfin + Custom Jellyfin Apple TV app -developed by myself-)

ffmpeg … -i "….mkv" -map 0:0 -map 0:2 -map -0:s \
  -codec:v:0 copy -tag:v:0 hvc1 -bsf:v hevc_mp4toannexb \
  -codec:a:0 copy -f hls -hls_segment_type fmp4 …
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:2 -> #0:1 (copy)

The -codec:v:0 copy is the key part — the HEVC HDR stream is passed through as-is and plays in HDR on the TV, with no tone mapping and negligible CPU.

One small thing on the client side, in case it's helpful: with a multi-variant HLS playlist (an HDR remux rendition plus an SDR fallback at the same bandwidth), the native AVPlayer tends to pick the SDR one unless the client specifically selects the VIDEO-RANGE=PQ variant. Once the client targets the HDR rendition, it plays great.

So the fMP4/HLS remux route looks like a genuinely useful option here — gentle on the server and it preserves HDR on the Apple TV. Just sharing in case it helps, and happy to go into more detail.

 

FFmpeg.Remux-2026-06-07_17-01-04_32ce8d77902368b0e4edd358b2059492_8848d63c.log

[visproduction 361]

Related?

 http://videoprocessor.org/lldv

 https://professionalsupport.dolby.com/s/article/HTML5-Browser-Support?language=en_US

[vdatanet 1623]

For Apple TV specifically, though, the mpv route has a few trade-offs that a native HLS + fMP4 (stream-copy) path avoids:

• It's a third-party engine. Bundling and maintaining mpv instead of the platform's own AVFoundation is a long-term cost, and it tends to lag behind OS changes.
• It breaks some native integrations. The clearest one for me is audio: routing sound to an AirPlay 2 device such as a HomePod doesn't behave the same as with the system player — with the native pipeline that just works (multichannel included); with a custom renderer it's often limited or lost.
• It tone-maps rather than passes through. This is the big one. As far as I can tell, the mpv path does its own tone-mapping and then outputs an HDR signal, which makes the TV switch into HDR. It's better than re-encoding on the server, but it's still a tone-map: the TV never receives the original Dolby Vision bitstream, so its own DV engine (with the dynamic, per-scene metadata) never gets to do its job. To my eyes it simply doesn't look identical to native DV passthrough.

That last point is why fMP4 remux matters. With HLS in an fMP4 container, the original HEVC/Dolby Vision stream can be stream-copied (no re-encode, no tone-map) and handed straight to AVPlayer, so tvOS does true native HDR/Dolby Vision + Match Content. I've got exactly this running on an Apple TV 4K now — DV Profile 8.1 remuxed losslessly, the TV switching into native Dolby Vision — so it's not theoretical.

None of this is mpv-vs-fMP4; ideally both exist. But for Apple TV users chasing reference-quality HDR, native remux is the one that looks right. +1 to finally adding it.