I'm starting to experience Hardware Transcode Keep Buffering on DS918+

1.32.6.7557 released and change log also doesn’t seem to indicate this issue has been handled.

May I know what keyword(s) I should look for to determine whatever fixes mentioned in the change log are related to this issue?

Thanks.

Update: Just tested. It doesn’t resolve the slow HW transcoding issue. Had to revert again.

May i separate this issue into the essential facets?

Facet 1 - No subtitles

  • J3455 CPU
  • No VaapiDriver="i965" preference asserted.
  • HW transcoding and tone mapping of 2160p HDR → 1080p H264

root@apollolake:/var/lib/plexmediaserver/Library/Application Support/Plex Media Server# cat /proc/cpuinfo | grep ‘model name’ | uniq
model name : Intel(R) Celeron(R) CPU J3455 @ 1.50GHz
root@apollolake:/var/lib/plexmediaserver/Library/Application Support/Plex Media Server# dpkg -l | grep plexm
ii plexmediaserver 1.32.6.7557-1cf77d501 amd64 Plex organizes all of your personal media so you can easily access and enjoy it.
root@apollolake:/var/lib/plexmediaserver/Library/Application Support/Plex Media Server#

Facet 2 - SRT subtitles

  • Same test conditions as #1 above

  • Add SRT type subtitles
    – Player set to “Automatic” or “No subtitles” modes

  • No stuttering of any kind.
    – The J3455 CPU easily multiplexes the SRT into the output as the 3rd stream with the Video and Audio.

Facet 3 - ASS / SSA subtitles - No burning

  • KNOWN - Conversion of ASS/SSA subtitles → SRT is more CPU intensive than it should be (long standing issue needing rewrite)

Facet 4 - Subtitle burning-in (of any kind)

  • 720p source video – Success likely
  • 1080p source video – Success possible (up to about 20 Mbps source material)
  • 2160p source video – Always fail, Insufficient internal CPU bandwidth to accomplish the task required in Software.

Given the above, Please help me clarify and focus on what the issue is here using these

Hi @ChuckPa,

I believe my problem is Facet 3 - ASS / SSA subtitles - No burning as the HW transcoding when playing anime (.mkv file) with internal .ass subtitles caused it to buffer. On my Samsung TV, it can show the transcoding rate and it is lower than 1.0, average at 0.7, thus the buffering.

PMS version 1.32.1.6999 and before it transcoding rate are above 1.0, average at 2.9. Below is a snapshot of the display of the information.

Thanks.

Thanks for this. It’s what I think I see in the FFMPEG code.

While I’m not sure entirely sure how to fix it yet, knowing we have “previous” which converts well compared to now, we can go find the changes made in FFMPEG (what was integrated from upstream core) and start looking for the cause.

Looking at Samsung TV’s API, I can see where it shows SSA support but not ASS so the conversion is required.

Thanks for helping with this.

Anyone else please ?

Hi @ChuckPa,

I’m seeing (#number) behind each of the items in the change log for updates. Are they the case number? If so, may I know the case number for facet 3 above?

Thanks.

Bumping to avoid being closed.

Ticket number for this was #14528.
It is marked as resolved.

Thanks. I haven’t seen any release with this ticket number yet. So I’m guessing it hasn’t been released yet. Will monitor the new release logs and test it out.

You’ll find all the subtitles and transcoding fixes,

with exception of the new 6.1 kernel problems ,

now released in 1.32.8

2 Likes

Synology DS918+. With everything after PMS 1.32.1.6999 I was seeing buffering with subtitles to the point where it was unwatchable. Very happy to confirm that this is resolved with the 1.32.8 beta – thanks very much to you and the team for your work sorting this out.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.