-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jellyfin unnecessarily remuxes movies with external .ass subtitles #1896
Comments
If preferred, I can privately share links to the files used, or can provide an account on the instance, to assist with bug reproduction and fixing. |
This is most likely error in reporting reason, I don't think Firefox can play P.S. @justjanne I've edited your post to remove the hostname. |
@JustAMan I actually checked the wrong file, the remuxing happens with this file, which is h264:
|
So Jellyfin-web doesn't support ASS subtitles yet? |
@onny it absolutely supports them just fine on Firefox, Chrome, etc — but apparently if the playback device is a Chromecast, they break. See the referenced issue above. |
The same happens when you play via DLNA |
@justjanne So this issue is a doppelganger for jellyfin/jellyfin-chromecast#14, right? @97carmine please create a separate issue about DLNA. |
@JustAMan As I couldn't be sure if they're related, or separate, I filed both as separate issues. Please close this issue if you consider it a duplicate |
This is what you were saying, which I interpreted as "if I use Firefox to view - subtitles work, but if I cast to Chromecast they're broken"... if this is so please close the issue. |
@JustAMan well, the encoding and handling of encoding would seem to be an issue with the jellyfin server, as it decides whether to re-encode a movie or not, independently of the client device. Presumably, the code checking for playability of the movie also checks if the subtitle format is supported, regardless of if it would end up in the final container or not |
But if you'd prefer to handle the issue with the server over on the Chromecast repo's issue tracker, I'll close this one. |
This isn't true. Right now it is the client device that reports its "profile" which actually states capabilities of the client device, and according to that capabilities the server decides how to proceed. However, come to think of it, this one is actually slightly separate, so let's leave it open until we can re-formulate it to make it clearer. |
@JustAMan well, regardless of the capabilities of the client device, this seems like a bug. If the client device wouldn't support ass subtitles, the video file (which on its own would be supported) should still use DirectStream and DirectPlay (as the video file doesn't even contain ass subtitles, neither before nor after the remuxing step) |
Seems as if it's related. Nvidia Shield TV. |
I think it's probably a different one. I believe we fixed playing |
@JustAMan it always worked on web player, not since 10.4.??? on Chromecast though |
pinging @YouKnowBlom |
This seems like an issue with the server rather than the old CC receiver @JustAMan |
How come? Server only decides to burn in if client does not report that it can play subtitles. |
It's likely I've misunderstood as this thread is a bit all over the place. So the bug is that ass/ssa subs are burned in, as well as being supplied to the client as a separate file, that then gets decoded by the client? Wouldn't that mean the client has support for those subtitle formats? Is this happening specifically on Chromecast or jf-web as well? |
Steps to Reproduce:
Expected: Actual: |
What happens with subtitles though, are they displayed by CC? As from what you said I think they weren't burnt in. Also giving us debug server logs of when playback starts (including ffmpeg command line) would be cool. |
@JustAMan Server logs are in the first post on this issue, are those enough or would you want loglevel debug logs? Also, no, subtitles aren’t displayed at all on Chromecast |
So I've looked into logs more, and it seems there are two seemingly unrelated issues, first one is CC reporting that it cannot play First one should be fixed when @YouKnowBlom finishes polishing our new CC receiver - I still hope we'd be able to integrate Octopus there, so CC would play For the second one I'm going to edit this issue so it reflects it better. @justjanne please verify I have edited correctly. Please also add some info on your instance configuration - whether transcoding and remuxing are enabled (or not). |
Nevermind sorry. |
This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments. |
Describe the bug
Jellyfin forces remuxing of movies if the subtitle format is unsupported — even if this is unnecessary (external ASS subtitles only played back by the custom JS subtitle decoder, never ending up in the video stream, supplied as external file)
ffmpeg -i output for affected files
To Reproduce
Expected behavior
In both cases, the file should be played back without any transcoding or remuxing (or subtitles have to be burnt in). Current behaviour is wrong anyway - it doesn't deliver subtitles because target device reports it cannot play those but it doesn't burn them in either.
Actual behavior
With subtitles enabled, the movie is remuxed, because of an unsupported subtitle format
Logs
More playback logs
System (please complete the following information):
The text was updated successfully, but these errors were encountered: