mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
Dolby Vision P5 HLS should use CODECS = dvh1 (instead of hvc1) #8114
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @DrHurt on GitHub (Feb 3, 2026).
Description of the bug
Edit:
Apple uses CODECS=dvh1 for P5 (without supplemental codecs).
Currently, Jellyfin uses CODECS=hvc1
=================
When playing an MKV DV P5 on a device that requires mp4/hls, the master playlist doesn't contain the SUPPLEMENTAL-CODECS so TV switches to HDR instead of DV.
With DV P8, SUPPLEMENTAL-CODECS is there and has a value of dvh1 which causes the TV to switch mode.
Manually adding the missing value causes the TV to switch correctly with P5.
Reproduction steps
Play MKV + DV P5 with a client that only supports mp4 (eg. Apple devices, Safari or Apple TV)
What is the current bug behavior?
tvOS & TV change to HDR mode because of incorrect signalling in the master.m3u8
What is the expected correct behavior?
master.m3u8 MUST contain SUPPLEMENTAL-CODECS = dvh1 with DV P5 (like it already does with P8)
Jellyfin Server version
10.11.6
Specify commit id
No response
Specify unstable release number
No response
Specify version number
No response
Specify the build version
.
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
No response
@DrHurt commented on GitHub (Feb 3, 2026):
@gnattu Can you please have a look. I believe you've worked on this before.
@nyanmisaka commented on GitHub (Feb 3, 2026):
The DV P5 does not include any HDR10 compatibility layer. Therefore, according to Apple documentation, SUPPLEMENTAL-CODECS should not be added.
https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices-appendixes#The-SUPPLEMENTAL-CODECS-attribute
https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices-appendixes#Example-playlist-with-SDR-Dolby-Vision-HDR10-and-HLG-content-at-resolutions-from-720p-to-4K
@DrHurt commented on GitHub (Feb 3, 2026):
Well, without it the Apple TV switches to HDR instead of DV mode.
I tried setting CODECS to dvh1 (instead of hvc1) without SUPPLEMENTAL-CODECS and that worked too and TV switched to DV mode.
Technically the base layer in P5 is DV so setting CODECS = dvh1 is the more correct approach.
@DrHurt commented on GitHub (Feb 3, 2026):
@nyanmisaka
So to sum up my findings, to get tvOS to change the TV to DV mode we need either
CODECS = dvh1
or
CODECS = hvc1 & SUPPLEMENTAL-CODECS = dvh1
Both seem to be working correctly but the former is the approach used by Apple in the examples link you provided above.
@DrHurt commented on GitHub (Feb 3, 2026):
The above link you posted shows Apple using CODECS=dvh1 for DV P5
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=24975091,BANDWIDTH=30041698,VIDEO-RANGE=PQ,CODECS="dvh1.05.06",RESOLUTION=3840x2160,FRAME-RATE=23.976,CLOSED-CAPTIONS=NONE,HDCP-LEVEL=TYPE-1
dolby_2160/prog_index.m3u8
@nyanmisaka commented on GitHub (Feb 3, 2026):
That's to maintain compatibility with some older devices such as LG TV that support Dolby Vision but was only compatible with the "hvc1" fourcc in the HLS playlist. We've already specified "dvh1" fourcc at the bitstream level, and iOS, iPadOS, and macOS can automatically detect it and switch to Dolby Vision P5. tvOS might be another exception.
@DrHurt commented on GitHub (Feb 3, 2026):
I think on all Apple devices, CODECS should be set to dvh1 to ensure the system sets up the correct playback pipeline and that the dynamic metadata is getting handled correctly.
This probably affects all other iOS & macOS devices too where the system likely uses the HDR pipeline instead of DV.
tvOS exposed the problem as the TV shows the mode switch where as macOS and iOS may be silently in HDR mode too (& potentially not correctly handling the dynamic metadata).
I don't know whether Apple or LG is the problem. I suspect Apple's approach is the correct one and LG is the one that needs a workaround. I think Jellyfin should be using dvh1 by default and have device specific exceptions for LG & others that need it.
@gnattu commented on GitHub (Feb 4, 2026):
IMO we should do something for those LG TVs in the future major version instead of punishing the client that follows the spec.
You are right that some TV needs this to use its native DV mode but in fact, for profile 5 and 8, they are low latency dv which means it does not necessarily require the display or tv itself to be DV compatible to display correct color. Apple uses this approach on all its internal displays, where the player (instead of the display) to handle the dynamic metadata. If the display characteristics passed to the player is accurate, player decoded and display(tv) decoded result should be identical. It is possible that the player got inaccurate info and the result looks different though.
Supporting HDR is always hard as we have tons of different devices, and even LG TVs differs from LG TVs, some android tv's hls implementation ignores video range entirely, and Apple devices tends to be too restrictive to the manifest. We may introduce some compatibility layers in the future but that is probably a lot of work, and it is also very hard to verify if the compatibility layer would work as we don't have very limited set of devices to test.
@DrHurt commented on GitHub (Feb 4, 2026):
Apple is indeed very strict but like you said, they are also specs compliant.
To be fair, JellyFin is also extremely specs compliant, and works incredibly well with Apple’s strict software. This problem is the first true deviation from that in my extensive testing.
I believe Jellyfin should remain strictly specs compliant by default unless such compliance would cause a majority of target devices to fail.
Judging by what you said, it sounds like this is mostly an LG webOS issue and that other devices even if less compliant, would still at least handle compliant HLS more gracefully.
Just (politely) thinking out loud here! You two are obviously a lot more knowledgeable and experienced than me. I appreciate all your contributions to this incredible project.