mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
Hardware acceleration blocks playback with certain formats #325
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @eoop on GitHub (Jan 24, 2019).
Describe the bug
If 10-bit h264 video is transcoded with NVENC hardware acceleration enabled FFmpeg will throw an error since 10-bit h264 transcoding is not supported on Nvidia hardware. Client side, the video will appear to be continuously loading.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
When playing video unsupported by hardware acceleration, fall back to software decoding/encoding.
Logs
System (please complete the following information):
Additional context
This may only be a problem on older non Nvidia Pascal GPUs, though it appears that Nvidia hardware acceleration does not support 10-bit h264 no matter the architecture. I am using a GTX 750.
@hawken93 commented on GitHub (Jan 25, 2019):
I think newer chips support 10 bit but I couldn't find documentation right away. Would be nice to have fallback logic if ffmpeg exits with an error or based on similar conditions.. Maybe also investigate if ffmpeg has a way to display the supported formats..
@EraYaN commented on GitHub (Jan 25, 2019):
Only for encode or videos encoded using
p010le, since you can't decode with converting the pixel format beforehand. The nvidia support matrix doesn't even mention 10-bit support for AVC. Only HEVC.@Evoley commented on GitHub (Jan 27, 2019):
I can add more information to this issue if needed as I thought it was due to the subtitles some files were using ( #695 ) .
@selkiess commented on GitHub (Feb 28, 2019):
Just to add more information to this issue to help with a better fix
While referenced as hardware acceleration above, specifically this bug has to do hardware decoding a h264 10 bit video.
this page from nvidia has decode/encode charts with supported bit depths:
https://developer.nvidia.com/nvidia-video-codec-sdk
Even turing does not have support for 10 bit decode or encode with h.264, only h.265
@stale[bot] commented on GitHub (Jul 30, 2019):
Issues go stale after 60d of inactivity. Mark the issue as fresh by adding a comment or commit. Stale issues close after an additional 7d of inactivity. If this issue is safe to close now please do so. If you have any questions you can reach us on Matrix or Social Media.
@selkiess commented on GitHub (Sep 29, 2019):
Would it be possible to reopen this issue? It is still a bug on the current version.
@joshuaboniface commented on GitHub (Sep 29, 2019):
Might be fixed as we move to ffmpeg 4.2 - stay tuned.
@Scrumplex commented on GitHub (Oct 15, 2019):
No matter if this specific issue will be fixed. There should definitely be something like an error screen for the player, so the user does not get frustrated, when some ffmpeg error occurs.
@RazeLighter777 commented on GitHub (Dec 8, 2019):
I am currently having this same issue. Basically, NVENC doesn't support 10bit h264 at all, even in the latest GPUs. Therefore, there should be logic in the program to let the CPU take over when there are no available ways to use hardware transcoding.
@RazeLighter777 commented on GitHub (Dec 8, 2019):
I have more information on this issue. After picking through the logs, I found out that basically the decoder doesn't support 10-bit h264 (h264_cuvid), but the encoder (h264_nvenc) does. Therefore, the solution is to use regular h264 as the decoder and h264_nvenc as the encoder. I imagine this reduces performance a little bit and hits the cpu, but it's still better than failing
Like this (see the part in **)
/usr/lib/jellyfin-ffmpeg/ffmpeg **-c:v h264** -resize 1920x1080 -i file:"10-bit_264_file.mkv" -map_metadata -1 -map_chapters -1 -threads 0 -map 0:0 -map 0:1 -codec:v:0 h264_nvenc -pix_fmt yuv420p -preset default -b:v 4371161 -maxrate 4371161 -bufsize 8742322 -profile:v high -force_key_frames:0 "expr:gte(t,0+n_forced*3)" -copyts -vf "subtitles='10-bit_264_file.mkv":si=0'" -vsync -1 -codec:a:0 aac -strict experimental -ac 2 -ab 192000 -f hls -max_delay 5000000 -avoid_negative_ts disabled -start_at_zero -hls_time 3 -individual_header_trailer 0 -hls_segment_type mpegts -start_number 0 -hls_segment_filename "/var/lib/jellyfin/transcoding-temp/transcodes/transcodes/transcodes/transcodes/481004b35d9b1472ecbe6bb041bb17fd%d.ts" -hls_playlist_type vod -hls_list_size 0 -y "/var/lib/jellyfin/transcoding-temp/transcodes/transcodes/transcodes/transcodes/481004b35d9b1472ecbe6bb041bb17fd.m3u8"Versus this:
/usr/lib/jellyfin-ffmpeg/ffmpeg **-c:v h264_cuvid** -resize 1920x1080 -i file:"10-bit_264_file.mkv" -map_metadata -1 -map_chapters -1 -threads 0 -map 0:0 -map 0:1 -codec:v:0 h264_nvenc -pix_fmt yuv420p -preset default -b:v 4371161 -maxrate 4371161 -bufsize 8742322 -profile:v high -force_key_frames:0 "expr:gte(t,0+n_forced*3)" -copyts -vf "subtitles='10-bit_264_file.mkv":si=0'" -vsync -1 -codec:a:0 aac -strict experimental -ac 2 -ab 192000 -f hls -max_delay 5000000 -avoid_negative_ts disabled -start_at_zero -hls_time 3 -individual_header_trailer 0 -hls_segment_type mpegts -start_number 0 -hls_segment_filename "/var/lib/jellyfin/transcoding-temp/transcodes/transcodes/transcodes/transcodes/481004b35d9b1472ecbe6bb041bb17fd%d.ts" -hls_playlist_type vod -hls_list_size 0 -y "/var/lib/jellyfin/transcoding-temp/transcodes/transcodes/transcodes/transcodes/481004b35d9b1472ecbe6bb041bb17fd.m3u8"As you can see this solution uses regular h264 for the decoding but h264_nvenc for the encoding.
I'm not too experienced with ffmpeg so if someone could chime in with this that would be cool.
@RazeLighter777 commented on GitHub (Dec 8, 2019):
@Scrumplex There is an error screen for me saying "no compatible streams" or something like that.
@davispuh commented on GitHub (Feb 14, 2020):
I'm also having this issue, logs show
I'm using NVENC on GeForce GTX 650 Ti.
@EraYaN commented on GitHub (Mar 9, 2020):
10-bit h264 will never be supported for hardware transcoding, no vendor has ever made a hardware implementation.
#2127 looks to at least make sure it correctly falls back to software transcoding.
@stale[bot] commented on GitHub (Jul 7, 2020):
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.
If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.
This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.