PGS Subs embedded my MKVs get misplaced after hardware transcoding

[Nauclerus 1]

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

[Luke 37246]

Hi, we are looking into this. Thanks for reporting.

[Nauclerus 1]

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 8356]

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]

@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]

@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

[chouyee 3]

@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 3]

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 3]

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 8356]

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 3]

13小时前， Happy2Play 说：

是的，因为这仅用于故障排除，并让开发人员知道 HWA 存在缩放问题。

所以它不是很实用。希望卢克能找到问题的根源。

[chouyee 3]

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 62]

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 3]

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

[chouyee 3]

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.

[Gecko 62]

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.

[chouyee 3]

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.

 

[Gecko 62]

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 3]

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 62]

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 3]

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 62]

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 3]

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.

[chouyee 3]

Follow up until the problem is resolved.

[chouyee 3]

Follow up until the problem is resolved.