jellyfin-roku
jellyfin-roku copied to clipboard
jellyfin
wip: HDR, VP9, AV1
This is starting off a little nasty but i figure we better get started. if anybody has the ability to test av1, please try this PR. ~~I suspect we also need to set up a valid mp4 transcoding profile in order to allow the directstream hevc functionality that the server is capable of, but i may also not understand what is going on.~~ - we do not. feedback welcome.
Unclear if this should have automatically fixed this or not as is, for the linked FR #685 but I tested this branch with an MKV DV file, and it did not transcode or trigger DV on the TV.
@Terebi42 It's unclear to me what you are saying here. What does "did not transcode or trigger DV on the TV" mean? I'd say "Not transcoding" is correct if your tv supports dovi, but what does "did not trigger dovi the tv" mean? sounds bad, right?
@Terebi42 It's unclear to me what you are saying here. What does "did not transcode or trigger DV on the TV" mean? I'd say "Not transcoding" is correct if your tv supports dovi, but what does "did not trigger dovi the tv" mean? sounds bad, right?
My TV supports DoVi, but apparently not in MKV containers for webdl (mkv works for bd rips, due to the profile 7?).
#685 was a request to remux these on the fly to improve support. (Apparently this is done in the safari client already)
if you show me where I'd be happy to replicate it. https://github.com/jellyfin/jellyfin-web/blob/7771ce716e4eab22f17a3354b9b0bd8e94e9291a/src/scripts/browserDeviceProfile.js there are only 12 hits for "safari" in the whole doc so we should be able to figure it out.
if you show me where I'd be happy to replicate it. https://github.com/jellyfin/jellyfin-web/blob/7771ce716e4eab22f17a3354b9b0bd8e94e9291a/src/scripts/browserDeviceProfile.js there are only 12 hits for "safari" in the whole doc so we should be able to figure it out.
Honestly, I'm not sure. Thats based off of a comment someone made in reddit, along with the following screenshot
https://www.reddit.com/r/PleX/comments/vs09ki/can_a_client_profile_fix_dovi_mkvs/iezhdci/
https://imgur.com/a/MbvAgjy
But also there is this remuxing util that may have some clues https://github.com/gacopl/dvmkv2mp4
So, I guess I need this explained to me. If DOVI is not being transcoded then DOVI is being delivered to the roku. The roku can't tonemap it, the server IS NOT tonemapping it (because there is no transcode), so DOVI is being passed through to your TV because there is no transcode. If this video file is playing and looks remotely correct, then it must be in DOVI because otherwise how it is properly displayed? If nothing is decoding it between the file on your server and the screen, then it is DOVI. Roku isn't magically tonemapping it down and outputting SDR from a DOVI stream, thats not possible.
relevant exchange from chat: whiteowl: the logic in https://github.com/jellyfin/jellyfin-roku/pull/686 should be used for the codec-profiles since not all rokus support hevc, therefore your unconditional hevc codec profile is inappropriate, right? neil: I’m not 100% sure it’s required. As that’s only saying what the codec conditions are supported. It’s still the direct play and transcoding profiles that say what particular codecs are supported.That said, it would do no harm to include logic to check at that point.
So, I guess I need this explained to me. If DOVI is not being transcoded then DOVI is being delivered to the roku. The roku can't tonemap it, the server IS NOT tonemapping it (because there is no transcode), so DOVI is being passed through to your TV because there is no transcode. If this video file is playing and looks remotely correct, then it must be in DOVI because otherwise how it is properly displayed? If nothing is decoding it between the file on your server and the screen, then it is DOVI. Roku isn't magically tonemapping it down and outputting SDR from a DOVI stream, thats not possible.
For DoVi BDDrip in Mp4 or Mkv, they appear to work universally (profile 7?)
For DoVi WebDls (Profile 6?) in MP4, they play correctly, trigger DoVi on the TV and have the right colors.
For Dovi WebDLs in mkv they do not trigger DoVi on the TV, and are purple/Green.
I am unsure why many setups can play WebDL DoVi from mp4 but not mkv. But this situation is apparently true for many hardware/software setups. Thats why that other tool for remuxing mkv to mp4 I linked exists, and also why places like PTP have rules about uploading in mp4 instead of mkv for DoVi. Also the Trash guide custom formats/profiles for Sonarr/Radarr ignoring DoVi WebDL are due to this issue. Lots of threads on PTP/HDB/etc talking about the issue, which layer/profile DoVi it is, which setups can play MKV vs cant, etc.
My request was just to try and have Jellyfin remux DoVi mkv to mp4, which hopefully leads to increased compatibility, and which apparently already works for some people in Safari Jellyfin per that other screenshot I linked.
Its not a matter of "just remux mkv to mp4 if it contains dovi". Safari also does NOT ""remux dovi mkv to mp4" what it does is remux ALL mkv to mp4 because safari does not support mkv containers. The roku DOES support mkv containers, so without breaking the existing profiles, what you are asking for is very complicated.
Unclear if this should have automatically fixed this or not as is, for the linked FR #685 but I tested this branch with an MKV DV file, and it did not transcode or trigger DV on the TV.
What do you see on your display in this case? Can you take a photo of it? What gives you the impression that it did not "trigger DV on the TV"
- edit, nevermind I see from your previous comment that they have improper coloration like you would expect.
My tv puts up hdr or Dolby logos when non sdr modes are activated
If it's not feasible to selectively remux Dolby vision, could an option to globally remux mkv be added that could be manually selected?
My tv puts up hdr or Dolby logos when non sdr modes are activated
If it's not feasible to selectively remux Dolby vision, could an option to globally remux mkv be added that could be manually selected?
it would be straightforward to just disable mkv support with a setting, maybe. neil has a knack for solutions to problems like these maybe he will come up with something.
from chat: zackoid — the reason that some dovi profiles "work" in mkv for that person is because those profiles also include a full HDR10 fallback layer. so they're not actually using the DV enhanced metadata, but they still play HDR. whereas profile 5 (and 6?) only have the DV layer. it's common for DV to only be supported in mp4 containers. so if you can accurately detect the presence of DV there wouldn't be any harm in remuxing whenever it is present. i don't think a standard remux translates all the metadata correctly so that is probably something that can't be handled on the roku end alone, but i'm not certain about that.
from chat: zackoid — the reason that some dovi profiles "work" in mkv for that person is because those profiles also include a full HDR10 fallback layer. so they're not actually using the DV enhanced metadata, but they still play HDR. whereas profile 5 (and 6?) only have the DV layer. it's common for DV to only be supported in mp4 containers. so if you can accurately detect the presence of DV there wouldn't be any harm in remuxing whenever it is present. i don't think a standard remux translates all the metadata correctly so that is probably something that can't be handled on the roku end alone, but i'm not certain about that.
Well, my TV separately gives logos for DV vs HDR. So either my TV is lying to me when a BD rip triggers DV that its really HDR, or its a more complicated container + DVprofile compatibility combination.
This pull request has been inactive for 21 days and will be automatically closed in 7 days if there is no further activity.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request has been closed because it has been inactive for 28 days. You may submit a new pull request if desired.
This PR actually seems to solve the HDR transcoding issue, so I'm in favour of doing a bit of work on this PR to get it into a state that we can merge it. There are a few minor issues with the device profile logic that I'm going to push changes for, but nothing that changes how this works.
I've tried to copy the AV1 support into its own PR (#776) but there have been some reports that this doesn't work, so I would propose that until we can get some confirmation of this from people who have Roku devices that support AVI (which I do not, I'm afraid) I would suggest we add a user preference to allow users to enable "experimental av1 support", and have it off by default. This means we can get it out to a wider audience for testing and feedback.
@Terebi42 Since DoVi is not specifically addressed in this PR and you already have an issue open for it (#685) can I suggest we use that to have a further discussion about DoVi and not complicate this PR any further. I have recently got a TV that supports DoVi so should be able test how things are working - although will need to chat with you in more detail about it I have no doubt.
This PR actually seems to solve the HDR transcoding issue, so I'm in favour of doing a bit of work on this PR to get it into a state that we can merge it. There are a few minor issues with the device profile logic that I'm going to push changes for, but nothing that changes how this works.
I've tried to copy the AV1 support into its own PR (#776) but there have been some reports that this doesn't work, so I would propose that until we can get some confirmation of this from people who have Roku devices that support AVI (which I do not, I'm afraid) I would suggest we add a user preference to allow users to enable "experimental av1 support", and have it off by default. This means we can get it out to a wider audience for testing and feedback.
@Terebi42 Since DoVi is not specifically addressed in this PR and you already have an issue open for it (#685) can I suggest we use that to have a further discussion about DoVi and not complicate this PR any further. I have recently got a TV that supports DoVi so should be able test how things are working - although will need to chat with you in more detail about it I have no doubt.
All HEVC content I've tried thus far, both 1080p SDR and 4K HDR10, direct plays without transcoding using PR #686.
AV1 starts to play but sticks and buffers endlessly. Mine sat at 33% until I stopped it trying to play back.
This pull request has been inactive for 21 days and will be automatically closed in 7 days if there is no further activity.
@Terebi42 Since DoVi is not specifically addressed in this PR and you already have an issue open for it (#685) can I suggest we use that to have a further discussion about DoVi and not complicate this PR any further. I have recently got a TV that supports DoVi so should be able test how things are working - although will need to chat with you in more detail about it I have no doubt.
sorry, I didn't see this comment before. Yes, I'm fine with deferring the dovi bit.
Not sure if it's on the server side or client side but I still seem to have the video transcoded to h264 when the audio requires transcoding.
General
Complete name : video.mkv
Format : Matroska
Format version : Version 4
File size : 8.30 GiB
Duration : 1 h 5 min
Overall bit rate : 18.1 Mb/s
Movie name : video
Encoded date : UTC 2022-08-22 00:56:21
Writing application : mkvmerge v68.0.0 ('The Curtain') 64-bit
Writing library : libebml v1.4.2 + libmatroska v1.6.4
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5@Main
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 5 min
Bit rate : 17.4 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.087
Stream size : 7.95 GiB (96%)
Writing library : x265 3.4hy:[Linux][GCC 7.5.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=1 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=96 / keyint=96 / gop-lookahead=0 / bframes=3 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=18000 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / vbv-maxrate=24500 / vbv-bufsize=24500 / vbv-init=0.6 / vbv-end=0.6 / vbv-end-fr-adj=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=0 / display-window=0 / master-display=G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1) / cll=826,166 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / no-concatenation / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.01 / no-opt-cu-delta-qp / no-aq-motion / hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0
Default : No
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : BT.2020
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 826 cd/m2
Maximum Frame-Average Light Level : 166 cd/m2
Audio
ID : 2
Format : E-AC-3 JOC
Format/Info : Enhanced AC-3 with Joint Object Coding
Commercial name : Dolby Digital Plus with Dolby Atmos
Codec ID : A_EAC3
Duration : 1 h 5 min
Bit rate mode : Constant
Bit rate : 768 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 360 MiB (4%)
Language : English
Service kind : Complete Main
Default : No
Forced : No
Complexity index : 16
Number of dynamic objects : 15
Bed channel count : 1 channel
Bed channel configuration : LFE
By default, audio always causes a transcode but the video shouldn't need transcoded. To test, I hardcoded eac3, 5.1 channel, and hevc main 10 support into the direct play profile and the video plays fine (the TV indicates it's HDR) but obviously no audio (since that codec isn't supported). Without hardcoding those into the direct play profile, I end up getting a transcoded stream with aac 2 channel audio and h264 video.
Not sure if it's on the server side or client side but I still seem to have the video transcoded to h264 when the audio requires transcoding.
General Complete name : video.mkv Format : Matroska Format version : Version 4 File size : 8.30 GiB Duration : 1 h 5 min Overall bit rate : 18.1 Mb/s Movie name : video Encoded date : UTC 2022-08-22 00:56:21 Writing application : mkvmerge v68.0.0 ('The Curtain') 64-bit Writing library : libebml v1.4.2 + libmatroska v1.6.4 Video ID : 1 Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Main 10@L5@Main HDR format : SMPTE ST 2086, HDR10 compatible Codec ID : V_MPEGH/ISO/HEVC Duration : 1 h 5 min Bit rate : 17.4 Mb/s Width : 3 840 pixels Height : 2 160 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 23.976 (24000/1001) FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 10 bits Bits/(Pixel*Frame) : 0.087 Stream size : 7.95 GiB (96%) Writing library : x265 3.4hy:[Linux][GCC 7.5.0][64 bit] 10bit Encoding settings : cpuid=1111039 / frame-threads=1 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=96 / keyint=96 / gop-lookahead=0 / bframes=3 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=18000 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / vbv-maxrate=24500 / vbv-bufsize=24500 / vbv-init=0.6 / vbv-end=0.6 / vbv-end-fr-adj=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=0 / display-window=0 / master-display=G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1) / cll=826,166 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / no-concatenation / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.01 / no-opt-cu-delta-qp / no-aq-motion / hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 Default : No Forced : No Color range : Limited Color primaries : BT.2020 Transfer characteristics : PQ Matrix coefficients : BT.2020 non-constant Mastering display color primaries : BT.2020 Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2 Maximum Content Light Level : 826 cd/m2 Maximum Frame-Average Light Level : 166 cd/m2 Audio ID : 2 Format : E-AC-3 JOC Format/Info : Enhanced AC-3 with Joint Object Coding Commercial name : Dolby Digital Plus with Dolby Atmos Codec ID : A_EAC3 Duration : 1 h 5 min Bit rate mode : Constant Bit rate : 768 kb/s Channel(s) : 6 channels Channel layout : L R C LFE Ls Rs Sampling rate : 48.0 kHz Frame rate : 31.250 FPS (1536 SPF) Compression mode : Lossy Stream size : 360 MiB (4%) Language : English Service kind : Complete Main Default : No Forced : No Complexity index : 16 Number of dynamic objects : 15 Bed channel count : 1 channel Bed channel configuration : LFEBy default, audio always causes a transcode but the video shouldn't need transcoded. To test, I hardcoded eac3, 5.1 channel, and hevc main 10 support into the direct play profile and the video plays fine (the TV indicates it's HDR) but obviously no audio (since that codec isn't supported). Without hardcoding those into the direct play profile, I end up getting a transcoded stream with aac 2 channel audio and h264 video.
Interesting. I'm running this PR and I'm pretty sure I now get correct direct stream functionality where I just get audio transcoding if needed. Previously, an audio transcode would force the video to be transcoded too. My server version is 10.7.7.
This was big 10.8.5 so possibly related to 10.8.x changes but not sure if it's on the Roku client side (device profiles) or server side (transcoding code)
I'll try again with 10.8.7 when I have some time but I didn't see any relevent changes in the changelog
After see this https://github.com/jellyfin/jellyfin/blob/a214ca259838fa7d1a7052b7bd7ba6a16720406f/MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs#L5516, I tried moving hevc and h265 to the beginning of the VideoCodecs list and that seems to have fixed it. Although, it seems like Jellyfin server should still attempt to avoid transcoding if the codec appears anywhere in the list
diff --git a/source/utils/deviceCapabilities.brs b/source/utils/deviceCapabilities.brs
index 96df7b3..37bb785 100644
--- a/source/utils/deviceCapabilities.brs
+++ b/source/utils/deviceCapabilities.brs
@@ -26,22 +26,21 @@ function getDeviceProfile() as object
maxAudioChannels = 6
end if
- if playMpeg2 and di.CanDecodeVideo({ Codec: "mpeg2" }).Result = true
- tsVideoCodecs = "h264,mpeg2video"
- else
- tsVideoCodecs = "h264"
- end if
-
addHevcProfile = false
MAIN10 = ""
+ tsVideoCodecs = "h264"
if di.CanDecodeVideo({ Codec: "hevc" }).Result = true
- tsVideoCodecs = tsVideoCodecs + ",h265,hevc"
+ tsVideoCodecs = "h265,hevc," + tsVideoCodecs
addHevcProfile = true
if di.CanDecodeVideo({ Codec: "hevc", Profile: "main 10" }).Result
MAIN10 = "|main 10"
end if
end if
+ if playMpeg2 and di.CanDecodeVideo({ Codec: "mpeg2" }).Result = true
+ tsVideoCodecs = tsVideoCodecs + ",mpeg2video"
+ end if
+
if di.CanDecodeAudio({ Codec: "ac3" }).result
tsAudioCodecs = "aac,ac3"
else
There seems to be a weird interaction with this block of code https://github.com/jellyfin/jellyfin/blob/master/Jellyfin.Api/Helpers/DynamicHlsHelper.cs#L201
Commenting out that block and using this branch as-is also results in the video file playing without any video transcoding. I'll open an issue in jellyfin/jellyfin
There seems to be a weird interaction with this block of code https://github.com/jellyfin/jellyfin/blob/master/Jellyfin.Api/Helpers/DynamicHlsHelper.cs#L201
Commenting out that block and using this branch as-is also results in the video file playing without any video transcoding. I'll open an issue in jellyfin/jellyfin
Cool! If you want, you might want to make mention of it in the Matrix Jellyfin Roku chat just to get eyes on it.
Just tried this with Neil's latest changes. From my quick testing, everything that worked for me previously (x264, x265, HDR) all worked and direct played as expected.
I tried to play an AV1 clip I got from https://www.elecard.com/videos (City Hall 1080p). With the forced direct play option all I got was a black screen which is consistent with when I tried this clip with an earlier version of this PR. The video is playing, but the screen is just black. Not sure why, but more importantly, when I disabled the AV1 direct play option the video was successfully transcoded. The Dashboard reported it was being transcoded into x265 which was cool as well.