betterize subtitle profiles

[whiteowl3]

most profiles i have looked at list multiple available methods for each format, so I have replicated that. The addition of ass and ssa profiles in particular prevents malfunctions with those types where they appear to require transcoding but in fact do not.

Changes add ass and ssa subtitle profiles to prevent failures with those types extend all textual profiles to include "embed" instead of only "external"

Issues

[whiteowl3]

in all likelihood fixes #666

[neilsb]

I'm not very knowledgeable about subtitle formats, and how the different abbreviations relate to the subtitle types/specs, however roku states that it only supports 3 formats

• SMPTE-TT
• EIA-608/708
• WebVTT

Although it clearly supports plain text based ones too (i.e. srt)

This PR looks like you're telling the server we support a lot more formats (ssa, pgs, smi, etc) which I don't think it necessarily supports. Certainly for ssa (or ass) subtitles, which I am somewhat familiar with, this PR introduces some issues.

For external subtitle streams, the subtitles are just not displayed at all.

For embedded subtitle streams, the are just displayed as standard text and lose text formatting and position information, which was how it worked originally but was changed to burn-in in #183, to keep similar to how other clients do it. If we're changing this behaviour I think we would need to at least add a user preference option for ssa to allow them to be burned in to keep the formatting.

[whiteowl3]

im no more knowledgeable than you are. i assumed these were underlying specifications which formats do or do not comply with. the intention is to tell the server that graphical subs need to be encoded (burned in) and everything else can be either external or embedded. ass/ssa is a unique problem on the roku because it will try to mung them to text, and whether it succeeds or fails cant be anticipated because ass/ssa can contain unpredictable stuff. my understanding was that roku would simply not display them when they were selected. it would be awesome if we could detect this and fail over to transcoding. all of my external subtitles, work with the changes. the subtitle profiles we report to the server should not affect the list of subtitles at all, right? it should only affect how particular formats are displayed to us. i agree that the correct way to handle ssa is to let the user make the choice based on their server resources.

[neilsb]

the subtitle profiles we report to the server should not affect the list of subtitles at all, right? it should only affect how particular formats are displayed to us.

That's correct. It should always supply the full set of subtitles. and what one the client request will determine whether the media needs transcoded (to burn them in) or can DirectPlay with the client handling the subtitle display (assuming the media is compatible, etc)

[github-actions[bot]]

This pull request has been inactive for 21 days and will be automatically closed in 7 days if there is no further activity.

[github-actions[bot]]

This pull request has been closed because it has been inactive for 28 days. You may submit a new pull request if desired.