So you have to read the info above this setting. Only ASS, PGS, VOB (possibly other graphical implementations supported by ffmpeg) are affected. This means there are significant areas where this setting does nothing to affect subtitle color (SRT, VTT, SUB, TTML, SMI, possibly IMX and other formats).
The only route you can hope to utilize would be altering the subtitles that you're looking to utilize if they're not in ASS or graphical format. That would be the subtitles filter in ffmpeg -- specifically the force_style modifier -- for batched conversion or a program like AegiSub, which would be one by one.
Subtitles filter info: https://ffmpeg.org/ffmpeg-all.html#toc-subtitles-1
Linux sample for batches of AVI, M4V, MKV, MOV, MPG, MP4, SRT, VTT, SUB files:
I'll test this in just a few minutes, it's a proof of concept at the moment. You may need to fiddle with settings to get the desired output. I'm also unsure of whether this filter would expect ASS for output (possible) so it may need to be adjusted in that fashion. Seems like this could be added as a feature, but I'm not certain of the reliability nor the impact for transcoding requirements.
Burning in requires transcoding, which would swap playback to SDR, since there is no HDR --> HDR transcoding. That would resolve the issue, but also preclude playback of HDR content at HDR levels.
The only route you can hope to utilize would be altering the subtitles that you're looking to utilize if they're not in ASS or graphical format. That would be the subtitles filter in ffmpeg -- specifically the force_style modifier -- for batched conversion or a program like AegiSub, which would be one by one.
Subtitles filter info: https://ffmpeg.org/ffmpeg-all.html#toc-subtitles-1
Linux sample for batches of AVI, M4V, MKV, MOV, MPG, MP4, SRT, VTT, SUB files:
Code:
for in in *.[amsv][4koprtUv][4Bgitv]; do \
ffmpeg -hide_banner -v warning -stats \
-i ${i} -c:s [copy|srt] \ # TTML not widely supported, must be converted to SRT
# Set the subtitle stream index or remove ":s" and set the overall stream index
# See list of video sizes (recommended): https://ffmpeg.org/ffmpeg-utils.html#toc-Video-size
# If you set FontName, include fontsdir
# ABGR not actual colorspace, special ASS format of: [ALPHA][BLUE][GREEN][RED], reversed HEX with first two digits for alpha
# NOTE: With video input file, using SRT/similar for filename renders/burns subs onto video
-filter:s:[X] "subtitles=filename=${i}:originalsize=hd1080:fontsdir=[/path/to/fonts]:stream_index=[X]:force_style='FontName=Arial,PrimaryColor=[ABGR_color]'" \
"${i%.[amsv][4koprtUv][4Bgitv]}.srt"
I'll test this in just a few minutes, it's a proof of concept at the moment. You may need to fiddle with settings to get the desired output. I'm also unsure of whether this filter would expect ASS for output (possible) so it may need to be adjusted in that fashion. Seems like this could be added as a feature, but I'm not certain of the reliability nor the impact for transcoding requirements.
(2024-05-16, 05:37 PM)Host-in-the-Shell Wrote: Are you by any chance forcing to burn all subtitles or perhaps playing media that has burn in subtitles such as DVDSUB? I find that these are always white regardless of what color you choose there; from my experience, the color only applies to external subtitles that do not require burn in such as SRT format (at least on WebOS, which is my daily driver client).
Burning in requires transcoding, which would swap playback to SDR, since there is no HDR --> HDR transcoding. That would resolve the issue, but also preclude playback of HDR content at HDR levels.
Jellyfin 10.10.0 LSIO Docker | Ubuntu 24.04 LTS | i7-13700K | Arc A380 6 GB | 64 GB RAM | 79 TB Storage