Are soft-subtitle settings controlled by UMS or by the TV?

For help and support with Universal Media Server
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
nouse
Posts: 30
Joined: Thu Jan 19, 2017 7:18 am

Re: Are soft-subtitle settings controlled by UMS or by the TV?

Post by nouse »

Thank you guys. That was very helpful.
Also kudos to @Madoka for their smooth taste :)

The subtitles are now running smoothly, in a much better readable font (actually, its resembling srt now).

I am curious: If i remove ass-support from the renderer configuration, why does it recognize that subtitles are in the folder? How does it still know that ass is a subtitle?
Nadahar
Posts: 1990
Joined: Tue Jun 09, 2015 5:57 pm

Re: Are soft-subtitle settings controlled by UMS or by the TV?

Post by Nadahar »

Removing the support simply means that UMS doesn't think the renderer can handle them. That means that UMS will transcode the video instead, burning the subtitles into the video stream. They are thus handled properly by the transcoding engine (FFmpeg, MEncoder etc).
nouse
Posts: 30
Joined: Thu Jan 19, 2017 7:18 am

Re: Are soft-subtitle settings controlled by UMS or by the TV?

Post by nouse »

Nadahar wrote: Tue May 01, 2018 9:21 pm Removing the support simply means that UMS doesn't think the renderer can handle them. That means that UMS will transcode the video instead, burning the subtitles into the video stream. They are thus handled properly by the transcoding engine (FFmpeg, MEncoder etc).
One last question.

I cannot fast forward the clips anymore for which UMS does the ass-rendering now instead of the tv. Is that normal?

Its not that crucial; its already a vast improvement from before, but i wonder if that is a design choice or inherited by the clip/subtitle combination.
Nadahar
Posts: 1990
Joined: Tue Jun 09, 2015 5:57 pm

Re: Are soft-subtitle settings controlled by UMS or by the TV?

Post by Nadahar »

When transcoding UMS is "generating" the video stream in real time. That makes seeking, fast forwarding etc complicated. It does normally work to some extent, but it's usually very delayed compared to when the file is streamed directly. On some renderers it doesn't work at all, which is usually caused by incompatibility between UMS and the renderer as far as I know. Some renderers use time codes and others use the number of bytes when requesting a new position, and there are some settings in the renderer configuration file for this. Testing different settings for this might make it work at least to some degree.
Post Reply