You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a bug, not a question or a configuration issue; Please visit our forum or chat rooms first to troubleshoot with volunteers, before creating a report. The links can be found here.
This issue is not already reported on GitHub(I've searched it).
I'm using an up to date version of Jellyfin Server stable, unstable or master; We generally do not support previous older versions. If possible, please update to the latest version before opening an issue.
This report addresses only a single issue; If you encounter multiple issues, kindly create separate reports for each one.
Description of the bug
Direct play behavior changes when server side hardware acceleration options are changed.
On my Roku 4802X, with MPEG2 compatibility enabled, it will direct play an MPEG2 video with AC3 audio in a TS container when hardware acceleration is set to Intel Quick Sync. The logs, intel_gpu_top, btop confirm that no ffmpeg process is spawned during playback on the Roku client.
When I switch hardware acceleration to "none", on the same Roku client with the same video, Jellyfin will transcode the video due to the client "not supporting the container".
Reproduction steps
Have a video with MPEG2 video, AAC or AC3 audio, in a TS container.
Enable MPEG2 compatibility on a Roku device
On the server go to Dashboard > Playback > Transcoding, and set the hardware acceleration drop down to none
Play the MPEG2 video.
What is the current bug behavior?
Depending on the HWA selection, the client playback behavior changes. Direct play when HWA is enabled, transcoding when HWA is none.
What is the expected correct behavior?
That this video would direct play, regardless if HWA is enabled or not. In general, whether HWA is enabled or not should not change whether a video is transcoded or direct played.
Jellyfin Server version
10.10.0+
Specify commit id
No response
Specify unstable release number
No response
Specify version number
No response
Specify the build version
10.10.0
Environment
OS: Ubuntu 24.04.1
Linux Kernel: 6.8.0-47-generic
Virtualization: Docker
Clients: Roku 4802X, Roku OS 14.0, JF app version 2.2.1
I think this should be moved to roku repo and from the log the direct play behavior just comes from the software transcoding took too long to initialize so the client just gives up and the server is using ffmpeg to transcode despite the HWA is enabled or not.
This issue respects the following points:
Description of the bug
Direct play behavior changes when server side hardware acceleration options are changed.
On my Roku 4802X, with MPEG2 compatibility enabled, it will direct play an MPEG2 video with AC3 audio in a TS container when hardware acceleration is set to Intel Quick Sync. The logs, intel_gpu_top, btop confirm that no ffmpeg process is spawned during playback on the Roku client.
When I switch hardware acceleration to "none", on the same Roku client with the same video, Jellyfin will transcode the video due to the client "not supporting the container".
Reproduction steps
What is the current bug behavior?
Depending on the HWA selection, the client playback behavior changes. Direct play when HWA is enabled, transcoding when HWA is none.
What is the expected correct behavior?
That this video would direct play, regardless if HWA is enabled or not. In general, whether HWA is enabled or not should not change whether a video is transcoded or direct played.
Jellyfin Server version
10.10.0+
Specify commit id
No response
Specify unstable release number
No response
Specify version number
No response
Specify the build version
10.10.0
Environment
Jellyfin logs
When HWA is set to none.
When HWA is set to Intel Quick Sync.
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
Forum user mentions that this has happened with all versions after 10.8.9.
https://forum.jellyfin.org/t-still-using-10-8-9
The text was updated successfully, but these errors were encountered: