Nauclerus 1 Posted April 21 Posted April 21 I've downloaded the latest and set up the Emby Server (Docker) environment and I've been thoroughly enjoying this wonderful application so far. I was using muxed MKVs with embedded subs (PGS) and it all worked perfectly. Direct play in 4K and Software Transcoding worked fine, both displayed the embedded subs perfectly well. I'll use Oppenheimer here as an example. (Subs here are located slightly to the left of the frame, that's due to the subs included and not a fault on Emby's part.) Of course when I confirmed all worked well, I had to try out Hardware encoding for more powerful conversion and the possibility for friends and family to access my repository remotely. Now I noticed multiple "shortcomings" that came with this: - A noticable green hue (compare the two images), alltough this might the fault of wrongly transcoded DV HDR filter (doing research on that) - When using the embedded subs (preferable due to perfect audio timing), I notice that when HARDWARE trancoding specifically, the subs seem to get misplaced, seemingly in the 1920x1080 quadrant of a 4k frame... but that is indeed very strange behaviour. Both transcode logs are included, aptly named. I will add that while both are pretty big downfalls, mostly the subtitle problem is actually dealbreaking as most of my users will need subtitles. I tried to download SRT subtitles as a substitution, that resulted in the following on the Web Client: The green hue remains, but the SRT subs are correctly displayed in the Web Client, Huzzah! I test on the Windows Theather app: Nothing... And the hue persists also here. When I try to get the PGS subs to work in here after a 4k > 1080p transcode just like in web player, they seems to shift to the wrong place. Of this last two screenshots there's also a ffmpeg log included, aptly named. I will admit that I've searched on this topic for quite a bit allready and nothing seems to resolve the subtitles missing or being misplaced. Is this a known issue? Has this been seen before? Any help would be GREATLY appreciated! Regards, Nauclerus ffmpeg-transcode-hardware.txt ffmpeg-transcode-software.txt ffmpeg-transcode-hardware-STRinEmbyTheaterDesktop.txt ffmpeg-transcode-hardware-SRTinWebClient.txt
Nauclerus 1 Posted April 21 Author Posted April 21 Thank you Luke, it's greatly appreciated. If it helps you in any way, within the ffmpeg logs I've noticed that a certain line indicates that something is missing. ``` 12:35:46.738 ffmpeg version 5.1-emby_2023_06_25 Copyright (c) 2000-2022 the FFmpeg developers and softworkz for Emby LLC 12:35:46.738 built with gcc 10.3.0 (crosstool-NG 1.25.0) 12:35:46.738 Execution Date: 2024-04-21 12:35:46 12:35:47.152 [matroska,webm @ 0x1476040] Could not find codec parameters for stream 2 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options ``` All the PGSsubs have this "error" and it attracted my attention concerning the weird placement of these subs (this excerpt was from the last included log)
Happy2Play 9060 Posted April 21 Posted April 21 (edited) Devs will know more but I used the diagnostic plugin and replaced canvas corrected the position issue in my test. Note this is subject to subtitle number being played ie s:x track number. Like a scaling mismatch Examples above >>>>>> Subtitle Processing Steps for [0:2]: HDMV PGS subtitles Step Format Target Size HDMV_PGS_SUBTITLE >> Subs: Bitmap scale >> Video: UNKNOWN 1920x1080 >>>>>> Video Processing Steps for [0:0]: H.265 (HEVC) Step HW-Context Format SW-Format Size Next HEVC >> CUDA cuda yuv420p10 3840x2160 >> scale_cuda scale_cuda >> CUDA cuda yuv420p10 1920x1080 >> setsar setsar >> CUDA cuda yuv420p10 1920x1080 >> setparams setparams >> CUDA cuda yuv420p10 1920x1080 >> tonemap_cuda tonemap_cuda >> CUDA cuda yuv420p 1920x1080 >> setparams setparams >> CUDA cuda yuv420p 1920x1080 >> hwdownload hwdownload >> - yuv420p yuv420p 1920x1080 >> format format >> - yuv420p yuv420p 1920x1080 >> format format >> - yuv420p yuv420p 1920x1080 >> overlay overlay >> - yuv420p yuv420p 1920x1080 >> 11:53:17.335 Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], Level 153, 23.98 fps, 23.98 tbr, 1k tbn (default) 11:53:17.335 Metadata: 11:53:17.335 BPS : 61451857 11:53:17.335 DURATION : 03:00:22.187000000 11:53:17.335 NUMBER_OF_FRAMES: 259473 11:53:17.335 NUMBER_OF_BYTES : 83130436755 11:53:17.335 Side data: 11:53:17.335 DOVI configuration record: version: 1.0, profile: 8, level: 6, rpu flag: 1, el flag: 0, bl flag: 1, compatibility id: 1 11:53:17.335 Stream #0:1(eng): Audio: dts (DTS-HD MA), 48000 Hz, 5.1(side), s32p (24 bit) (default) 11:53:17.335 Metadata: 11:53:17.335 title : DTS-HD MA 5.1 11:53:17.335 BPS : 3566822 11:53:17.335 DURATION : 03:00:22.155000000 11:53:17.335 NUMBER_OF_FRAMES: 1014577 11:53:17.335 NUMBER_OF_BYTES : 4825087720 11:53:17.335 Stream #0:2(eng): Subtitle: hdmv_pgs_subtitle, 3840x2160 11:53:17.553 subtitle input filter: decoding size 3840x2160 11:53:17.553 Auto-inserting subfeed filter 11:53:17.553 Auto-inserting graphicsub2video filter 11:53:25.617 Output #0, segment, to '/storage/temp/transcoding-temp/C5AD24/C5AD24_%d.ts': 11:53:25.617 Metadata: 11:53:25.617 encoder : Lavf59.27.100 11:53:25.617 Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 14616 kb/s, 23.98 fps, 90k tbn Edited May 4 by Happy2Play
Nauclerus 1 Posted April 22 Author Posted April 22 @Happy2PlayThank you very much for your input, you've let me discover this nice plugin, lots of handy buttons and switches indeed. I've been tinkering this morning and at one point I succeeded in getting the subtitles right! Unfortunately in all my enthusiasm I rebooted the server to verify and wiped my diagnostics settings with it. I also can't seem to find thew exact ffmpeg log wherein it worked, I can only blame myself. Nevertheless I've been pouring over logs and even in instances where it isn't correctly displayed, the logs are pretty similar to your excerpts: Quote >>>>>> Subtitle Processing Steps for [0:2]: HDMV PGS subtitles Step Format Target Size HDMV_PGS_SUBTITLE >> Subs: Bitmap scale >> Video: UNKNOWN 1920x1080 >>>>>> Processing Plan Name CanDoInHW WillDoInHW Reason NVDEC Quadro P2000 - H.265 (HEVC) >> True True Hardware Codec VideoInput >> True True Matching hardware context Scaling >> True True ToneMapping (when possible) >> True True SubtitleOverlay >> False False VideoOutput >> True True Hardware encoder NVENC Quadro P2000 - H.264 (AVC) >> True True Hardware Codec >>>>>> Video Processing Steps for [0:0]: H.265 (HEVC) Step HW-Context Format SW-Format Size Next HEVC >> CUDA cuda yuv420p10 3840x2160 >> scale_cuda scale_cuda >> CUDA cuda yuv420p10 1920x1080 >> setsar setsar >> CUDA cuda yuv420p10 1920x1080 >> setparams setparams >> CUDA cuda yuv420p10 1920x1080 >> tonemap_cuda tonemap_cuda >> CUDA cuda yuv420p 1920x1080 >> setparams setparams >> CUDA cuda yuv420p 1920x1080 >> hwdownload hwdownload >> - yuv420p yuv420p 1920x1080 >> format format >> - yuv420p yuv420p 1920x1080 >> format format >> - yuv420p yuv420p 1920x1080 >> overlay overlay >> - yuv420p yuv420p 1920x1080 >> Quote 09:25:32.154 subtitle input filter: decoding size 3840x2160 09:25:32.154 Auto-inserting subfeed filter 09:25:32.154 Auto-inserting graphicsub2video filter 09:25:40.245 Output #0, segment, to '/storage/temp/transcoding-temp/297BD4/297BD4_%d.ts': 09:25:40.245 Metadata: 09:25:40.245 encoder : Lavf59.27.100 09:25:40.245 Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 14616 kb/s, 23.98 fps, 90k tbn 09:25:40.245 Metadata: 09:25:40.245 encoder : Lavc59.37.100 h264_nvenc 09:25:40.245 Side data: 09:25:40.245 cpb: bitrate max/min/avg: 14616000/0/14616000 buffer size: 29232000 vbv_delay: N/A 09:25:40.245 Stream #0:1(eng): Audio: ac3, 48000 Hz, 5.1, fltp, 384 kb/s (default) 09:25:40.245 Metadata: 09:25:40.245 encoder : Lavc59.37.100 ac3 Despite this, the subtitles remain incorrectly displayed in the top-left quadrant
Nauclerus 1 Posted April 22 Author Posted April 22 @Happy2Play@Luke It seems I've been a little bit of an idiot concerning the -canvas_size:s:1 substitution... As I inspected the used ffmpeg command in my logs, I noticed that it contained -canvas_size:s:0 instead of -canvas_size:s:1. After changing that in command substitution using the Diagnostic plugin I can now reliably get the subtitles to show up correctly. Log attached of a successful encode using these options. Thank you so very much for this! This allows the server to be used for it's intended purpose for now at least, until Luke and the team find a solution to this problem. ffmpeg-transcode-Diagnostic_Resize_Works.txt 1
chouyee 5 Posted May 4 Posted May 4 @Happy2Play @Nauclerus I used the method you mentioned, and it worked. But now there is a very serious problem, -canvas_size:s:1 is not always the same, it could be -canvas_size:s:0, it could be -canvas_size:s:5.
chouyee 5 Posted May 4 Posted May 4 On 4/22/2024 at 6:36 AM, Happy2Play said: Devs will know more but I used the diagnostic plugin and replaced canvas corrected the position issue in my test. Like a scaling mismatch Examples above >>>>>> Subtitle Processing Steps for [0:2]: HDMV PGS subtitles Step Format Target Size HDMV_PGS_SUBTITLE >> Subs: Bitmap scale >> Video: UNKNOWN 1920x1080 >>>>>> Video Processing Steps for [0:0]: H.265 (HEVC) Step HW-Context Format SW-Format Size Next HEVC >> CUDA cuda yuv420p10 3840x2160 >> scale_cuda scale_cuda >> CUDA cuda yuv420p10 1920x1080 >> setsar setsar >> CUDA cuda yuv420p10 1920x1080 >> setparams setparams >> CUDA cuda yuv420p10 1920x1080 >> tonemap_cuda tonemap_cuda >> CUDA cuda yuv420p 1920x1080 >> setparams setparams >> CUDA cuda yuv420p 1920x1080 >> hwdownload hwdownload >> - yuv420p yuv420p 1920x1080 >> format format >> - yuv420p yuv420p 1920x1080 >> format format >> - yuv420p yuv420p 1920x1080 >> overlay overlay >> - yuv420p yuv420p 1920x1080 >> 11:53:17.335 Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], Level 153, 23.98 fps, 23.98 tbr, 1k tbn (default) 11:53:17.335 Metadata: 11:53:17.335 BPS : 61451857 11:53:17.335 DURATION : 03:00:22.187000000 11:53:17.335 NUMBER_OF_FRAMES: 259473 11:53:17.335 NUMBER_OF_BYTES : 83130436755 11:53:17.335 Side data: 11:53:17.335 DOVI configuration record: version: 1.0, profile: 8, level: 6, rpu flag: 1, el flag: 0, bl flag: 1, compatibility id: 1 11:53:17.335 Stream #0:1(eng): Audio: dts (DTS-HD MA), 48000 Hz, 5.1(side), s32p (24 bit) (default) 11:53:17.335 Metadata: 11:53:17.335 title : DTS-HD MA 5.1 11:53:17.335 BPS : 3566822 11:53:17.335 DURATION : 03:00:22.155000000 11:53:17.335 NUMBER_OF_FRAMES: 1014577 11:53:17.335 NUMBER_OF_BYTES : 4825087720 11:53:17.335 Stream #0:2(eng): Subtitle: hdmv_pgs_subtitle, 3840x2160 11:53:17.553 subtitle input filter: decoding size 3840x2160 11:53:17.553 Auto-inserting subfeed filter 11:53:17.553 Auto-inserting graphicsub2video filter 11:53:25.617 Output #0, segment, to '/storage/temp/transcoding-temp/C5AD24/C5AD24_%d.ts': 11:53:25.617 Metadata: 11:53:25.617 encoder : Lavf59.27.100 11:53:25.617 Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 14616 kb/s, 23.98 fps, 90k tbn On 4/22/2024 at 6:19 PM, Nauclerus said: @Happy2Play@Luke It seems I've been a little bit of an idiot concerning the -canvas_size:s:1 substitution... As I inspected the used ffmpeg command in my logs, I noticed that it contained -canvas_size:s:0 instead of -canvas_size:s:1. After changing that in command substitution using the Diagnostic plugin I can now reliably get the subtitles to show up correctly. Log attached of a successful encode using these options. Thank you so very much for this! This allows the server to be used for it's intended purpose for now at least, until Luke and the team find a solution to this problem. ffmpeg-transcode-Diagnostic_Resize_Works.txt 94.21 kB · 2 downloads I used the method you mentioned, and it worked. But now there is a very serious problem, -canvas_size:s:1 is not always the same, it could be -canvas_size:s:0, it could be -canvas_size:s:5.
chouyee 5 Posted May 4 Posted May 4 Now I know that the '3' in '-canvas_size:s:3' represents the number of subtitles. But in every movie, I don't always need the title '3'. So, do I need to change this code every time I watch a movie?
Happy2Play 9060 Posted May 4 Posted May 4 16 hours ago, chouyee said: Now I know that the '3' in '-canvas_size:s:3' represents the number of subtitles. But in every movie, I don't always need the title '3'. So, do I need to change this code every time I watch a movie? Yes as this is just for troubleshooting and lets the devs know there is a scaling issue with HWA.
chouyee 5 Posted May 5 Posted May 5 13小时前， Happy2Play 说： 是的，因为这仅用于故障排除，并让开发人员知道 HWA 存在缩放问题。 所以它不是很实用。希望卢克能找到问题的根源。
chouyee 5 Posted May 5 Posted May 5 13 hours ago, Happy2Play said: Yes as this is just for troubleshooting and lets the devs know there is a scaling issue with HWA. So it's not very practical. Hopefully Luke will get to the root of the problem.
Gecko 69 Posted May 5 Posted May 5 Just replace « 3840:2160 » by « 1920:1080 » in the plugin and don’t bother with the canvas text… unfortunately, everytime Emby restarts, you’ll have to remember to set those 2 texts again in the plugin.
chouyee 5 Posted May 6 Posted May 6 (edited) 17 hours ago, Gecko said: Just replace « 3840:2160 » by « 1920:1080 » in the plugin and don’t bother with the canvas text… unfortunately, everytime Emby restarts, you’ll have to remember to set those 2 texts again in the plugin. Do you mean that '-canvas_size:s:1 "3840:2160"' in '-canvas_size:s:1' does not need to be filled in, leaving only "3840:2160"? Edited May 6 by chouyee 1
chouyee 5 Posted May 6 Posted May 6 17 hours ago, Gecko said: Just replace « 3840:2160 » by « 1920:1080 » in the plugin and don’t bother with the canvas text… unfortunately, everytime Emby restarts, you’ll have to remember to set those 2 texts again in the plugin. Thank you, according to your method, now I can switch subtitles can work normally, and the location of subtitles is OK. 1
Gecko 69 Posted May 6 Posted May 6 Yeah just 3840:2160 in the 1st box and 1920:1080 in the 2nd. The issue does not seems to happen when transcoding 4K to 4K because there is no rescale at this stage, no rescale means nothing to replace. when transcoding from 4K to something else, rescaling happens, and the substitution kicks in. 1920:1080 is good wether you target 1080p’or lower resolution (but I don’t know why). anyway, doing this since the first beta 4.8, and it’s a rock solid workaround. 1
chouyee 5 Posted May 6 Posted May 6 1 hour ago, Gecko said: Yeah just 3840:2160 in the 1st box and 1920:1080 in the 2nd. The issue does not seems to happen when transcoding 4K to 4K because there is no rescale at this stage, no rescale means nothing to replace. when transcoding from 4K to something else, rescaling happens, and the substitution kicks in. 1920:1080 is good wether you target 1080p’or lower resolution (but I don’t know why). anyway, doing this since the first beta 4.8, and it’s a rock solid workaround. Unfortunately, I have found a new problem. Some of my videos are not the standard 3840X1920 resolution, such as 3840X1636, and I think the black edge was cut when pressing the movie, so the plugin changes will not take effect. 1
Gecko 69 Posted May 6 Posted May 6 I only have bluray remuxes so they are all in the proper resolution. In your case then yes, the substitution is not performed because of the difference in pixel height if you have a small amount of movies in such resolution, maybe it’s best to download another version or reprocess it… at least until a real solution is found by the devs.
chouyee 5 Posted May 6 Posted May 6 1 minute ago, Gecko said: I only have bluray remuxes so they are all in the proper resolution. In your case then yes, the substitution is not performed because of the difference in pixel height if you have a small amount of movies in such resolution, maybe it’s best to download another version or reprocess it… at least until a real solution is found by the devs. Yeah, I just have to hope Luke can figure it out. But I don't have much hope because this problem has been around for more than two years.
Gecko 69 Posted May 6 Posted May 6 3 hours ago, chouyee said: Yeah, I just have to hope Luke can figure it out. But I don't have much hope because this problem has been around for more than two years. The fix is known by Luke and the team if I recall correctly: deep analyse the media and compute the unknown size of each bitmap subtitle when not available in the metadata. but that would apparently slow down too much the media scan task so… not implemented in the end.
chouyee 5 Posted May 7 Posted May 7 13 hours ago, Gecko said: The fix is known by Luke and the team if I recall correctly: deep analyse the media and compute the unknown size of each bitmap subtitle when not available in the metadata. but that would apparently slow down too much the media scan task so… not implemented in the end. Well, just wait for the authorities. Then Jellyfin did just fine.
Gecko 69 Posted May 7 Posted May 7 Jellyfin works better but has an ui ugly as hell for my taste and I do like the way Emby works with the skip intro functionality. I miss h265 encoding though… maybe I’ll give it a try again this year to see the improvements.
chouyee 5 Posted May 8 Posted May 8 23 hours ago, Gecko said: Jellyfin works better but has an ui ugly as hell for my taste and I do like the way Emby works with the skip intro functionality. I miss h265 encoding though… maybe I’ll give it a try again this year to see the improvements. I agree with you that Jellyfin's transcoding and tone-mapping performance is much better than Emby's. But the Jellyfin UI was really ugly, and the TV client was really, really hard to use.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now