Strange transcode w/PGS subs failure

[rotational467 43]

Hi there,

Posting this under the server section although I haven't ruled out the Roku client yet, and this may be an issue with the media files.

Server is Emby 4.7.6.0 on Ubuntu 20.04.5 LTS w/HWE.  Hardware enc/dec enabled for Intel 630 GPU, latest Intel non-free drivers installed

I have a number of series ripped from BR with PGS subs intact.  I understand that PGS are not optimal but for various boring reasons I prefer them, and normally they do not cause any issues in my setup.  However last night I ran across a set of files that repeatedly failed to transcode when streaming to Roku when subs were enabled.  This is extremely unusual as my wife's user account has subs always enabled, and most of my media has PGS subs.

Failing: Futurama Season 6 (I tried multiple episodes, the "test" episode is S06E19).  The intro (no subs) plays normally, and then just prior to the first frame with subs, playback stalls, and transcoding attempts to start/reset and stalls at 65%.  Eventually Emby gives up and moves to the next episode and the behavior repeats.

Working: Battlestar Galactica 2003 Season 1 (test episode S01E06).  Transcode starts quickly and normally, no issues with subs.

Noticed in the various logs when failing:

Futurama (no dimensions/resolution listed for PGS):

>>>>>>  Subtitle Processing Steps for [0:2]: HDMV PGS subtitles
        Step                    Format             Target Size 
        HDMV_PGS_SUBTITLE    >> Subs: Bitmap                  
        scale                >> Video: UNKNOWN     1920x1080

BSG (PGS has normal 1080p dimensions):

>>>>>>  Subtitle Processing Steps for [0:2]: HDMV PGS subtitles
        Step                    Format             Target Size 
        HDMV_PGS_SUBTITLE    >> Subs: Bitmap       1920x1080   
        scale                >> Video: UNKNOWN     1916x-2

 

ffmpeg log error for Futurama:

"Impossible to convert between the formats supported by the filter 'hwupload@f4' and the filter 'auto_scale_0'"

There appears to be something up with either the Futurama subs or ffmpeg's ability to probe them, but I'm not sure what or how to address it.

I ripped and encoded both of these (and pretty much everything I have with PGS) myself, and these two specific shows were done with the same hardware/software/config within 2-3 weeks of each other.  I don't see any meaningful deltas between the two in the files' mediainfos.  The Futurama files play w/subs normally in VLC & MPC-BE.  Attached are file mediainfos, Emby server hardware detection, server logs, and ffmpeg logs showing both the BSG episode transcoding normally and the Futurama episode failing.  Logs were captured after a reboot of the Emby server and Roku client in question.  Note that eventually about half the Futurama episode was watched with subs OFF just to make sure it would otherwise play back normally.

These were encoded some time ago (2018) and I know that these Futurama episodes have played properly w/subs on MPC/VLC, Kodi (direct), and Plex.  I'd like to say definitively that they've worked on Emby previously at some point since I switched from Plex a few months ago, but I'm not 100% sure.

Thanks!

embyserver.txt ffmpeg-transcode-11fcb050-57c2-43b3-8950-14dee06bcc3d_1.txt ffmpeg-transcode-c05f620b-fbe2-449b-8be8-e0eb6aec4955_1.txt hardware_detection-63797741391.txt

Edited September 3, 2022 by rotational467

[softworkz 5066]

Could you please try with QuickSync?

Just go to Transcoding, choose Advanced and move the QuickSync encoders and decoders to the top

Thanks

[rotational467 43]

No problem, I will give that a try tomorrow and report back.  Thanks!

[rotational467 43]

QuickSync moved to top for all transcode types.  Server and Roku restarted after change and before testing. @softworkz

Futurama:

Same failure to play subs.  Eventually falls back to software (which works).  Quicksync seemed to have a lot of trouble with the file, buffering multiple times during the intro before dying completely at the first subtitles.

BSG:

Played normally and subs worked.

Both:

Corrupted video for first ~ 5 seconds of playback, bad aliasing during fast camera pans/high speed motion.  Remember the same kind of thing trying out QS with Plex in the before-time so I don't think that's anything out of the ordinary, at least on the 8700K.

It seems that there must be some kind of defect in the Futurama files, and I'd rather just dig out the discs and re-rip them than end up neck deep in a rabbit hole if the answer isn't apparent.  AFAIK everything else x265/PGS that I have, Emby streams to all of my clients/platforms with zero issues using VAAPI when xcoding is needed.  The Emby logs from these tests are attached in case you could get something useful...I can't see any difference in the files' metadata in either MediaInfo or mkvToolnix.

ffmpeg...6787_1 - First playback attempt of Futurama

ffmpeg...52fc_1 - Last playback attempt with QS HW xcoding

ffmpeg...d0f0_1 - Fallback to software xcoding playback

ffmpeg...7c98_1 - Playback of BSG with QS HW xcoding

 

Thanks again!

embyserver.txt ffmpeg-transcode-9c4b0e1a-93c1-473b-8ac9-211ae0bc6787_1.txt ffmpeg-transcode-683b710f-1706-4085-a20f-430cc393d0f0_1.txt ffmpeg-transcode-b9eb28db-acb4-4e6f-84e4-b72b47237c98_1.txt ffmpeg-transcode-bd03749d-5754-4165-8efe-15f5bd3552fc_1.txt hardware_detection-63797900532.txt

[softworkz 5066]

@Luke => range requests

[Luke 42078]

@rotational467 are you still running into this with Emby Server 4.7.11 and the latest version of Emby for Roku?

[rotational467 43]

@Luke I'm afraid it's still happening with server 4.7.11 and Roku client 4.0.75.  Same media file I originally used to report this and same behavior as previously.  Was able to see the transcode fail and restart multiple times on the user sessions panel (can't grab logs right now).  Screenshot attached while it was mid-fail/recovering.

edit: was able to grab the ffmpeg log, attached.

ffmpeg-transcode-585a5720-b84f-4ad5-b4c9-9571232c52cd_1.txt

Edited February 22, 2023 by rotational467
added log

[Luke 42078]

5 hours ago, rotational467 said:

@Luke I'm afraid it's still happening with server 4.7.11 and Roku client 4.0.75.  Same media file I originally used to report this and same behavior as previously.  Was able to see the transcode fail and restart multiple times on the user sessions panel (can't grab logs right now).  Screenshot attached while it was mid-fail/recovering.

edit: was able to grab the ffmpeg log, attached.

ffmpeg-transcode-585a5720-b84f-4ad5-b4c9-9571232c52cd_1.txt 23.67 kB · 1 download

Hi, please attach the main emby server log as well. thanks.

[rotational467 43]

@Luke Here it is.  Timestamp in question is 09:30 near the end.

embyserver-63812658622.txt

[Luke 42078]

@rotational467if you'd like to try the beta server, we think this will be resolved there in 4.8.0.33+.

Please let us know if this helps. Thanks !

[rotational467 43]

@Luke I may be able to try .34+ this weekend...must be careful not to pull wife aggro  Will report back w/logs if I am able to test.

Edited May 5, 2023 by rotational467

[rotational467 43]

@LukeWas able to reproduce with 4.8.0.34:

System drive crashed Friday, so this was a clean install of .34 on Ubuntu 22.04 HWE kernel and intel iHD 23.1.4 media driver.  Appears to be the same behavior and log output as I saw on 4.7 and the 22.x Intel driver.

On a side note I'm sorry this is in the Linux forum since it's apparently specific to the Roku, no idea if this behavior happens with a Windows server.

hardware_detection-63819094241.txt ffmpeg-transcode-4f6eff57-027c-4e8b-849b-4ad6ab0a3664_1.txt embyserver.txt

[rotational467 43]

Some more information.  I will do more thorough testing tomorrow but:

I took the source file used in the test above (which I did not rip) and ran it through mkclean with the --keep-cues and --remux switches (I'll do one at a time next time).  This resulted in successful playback, although you'll see in the log it struggled for some reason near the start.  This showed up as a few seconds of no sound and high-speed video playback.  The point at which the problem started is the exact same point where playback/transcoding fails in the first test.  After this, playback was perfectly fine.

This is AVC in MKV, I believe I have some HEVC in MKV that I've tested with this problem before that I ripped myself, but had not put the files through mkclean.  I will dig through and do more testing tomorrow.

embyserver (1).txt ffmpeg-transcode-2118940d-6e53-43b6-ac0b-50709124d7b3_1.txt

Edited May 8, 2023 by rotational467
more info

[Luke 42078]

That’s interesting. Let us know how it goes for Hevc. Thanks.

[rotational467 43]

@LukeOK, can tell you what works but not why!

The combination of the following mkclean switches produced a perfectly working version of the file used in testing above:

--remux       redo the Clusters layout
--live        the output file resembles a live stream

Neither switch alone is sufficient to make whatever modifications are necessary for emby to play it back without issue.  I tried this with some other files, but there's something broken in mkclean v.9+ on linux and I need to get some sample files on my Windows machine for reliable testing.  I'm hopeful though that this info is useful.

Just so I don't lose track, this issue is Emby failing to transcode PGS subs in an MKV container for a Roku client.

ffmpeg-transcode-9a00496a-d218-4b1f-8898-9bab4d2e3c84_1.txt embyserver (3).txt

Edited May 8, 2023 by rotational467
more info

[rotational467 43]

OK I'm at a loss.  Tried this morning with an HEVC which I ripped that I've seen the problem on before, the problem persists after running the above mkclean switches on it.

If sample files would be of any value, I can provide them.

embyserver.txt ffmpeg-transcode-08769c53-47c4-4ce2-bc82-0b1311e6d4b9_1.txt

Edited May 9, 2023 by rotational467

[rotational467 43]

I've moved this to the Testing area as it's still happening under 4.8.0.36, and it's not limited to the Roku client.