More > JRiver Media Center 29 for Windows

Feature Request: alternative subtitle renderer

<< < (2/3) > >>

Hendrik:
A lot of work already went into subtitle performance with JRVR for MC29, if these problems persist once you can test with MC29, then a sample and all required attachments would be appreciated.

bogdanbz:
Well, here it is, a 12 seconds mkv fragment (89 MB I'm afraid). I kept the video, but removed the audio: https://files.catbox.moe/plcb8h.mkv

I recommend to first play it without subtitles enabled, just to see what is the video content, and then play it with the subs enabled (the video gets stuck on a frame when playing with subs enabled).

Btw, this file also shows a bug in MC28: the subtitle track is not visible in the context menu Subs submenu, although the subtitles are rendered, and can be turned off by selecting "Off" in that submenu. I used the latest mkvtoolnix to make this sample, by the way.

(JRiver is confugured to use JRVR with Jinc scaling for both luma and chroma to 4K resolution at 60 Hz, for SDR 10 bit output; no advanced scaling enabled, no SuperRes, no dithering)

Hendrik:
Thanks, this subtitle is definitely still a bit slow, although already much better then in MC28. Going to work on some more improvements.
The reason its so slow is that this one scene has over 10000 individual subtitle elements. But I'll see what I can do about that.

bogdanbz:
Thanks for looking into it. I believe one trick used by XySubFilter and madVR is to render the subtitles at a lower resolution instead of the actual screen resolution (the max resolution at which to render the subtitles can be configured in the subtitle filter settings), and let the renderer scale the resulting bitmaps to the target resolution with the usual scaling algorithm.

Hendrik:
Definitely considered such an option before, and for 4K playback it may be required to play a variety of very complex subtitles. The subtitle rendering alone takes ~25ms now at 1080p after some optimizations, and that is before we do any further processing to get it actually onto the image (which is the real bottleneck now that is being worked on).

Navigation

[0] Message Index

[#] Next page

[*] Previous page