-
-
Notifications
You must be signed in to change notification settings - Fork 784
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
[Bug Report] Intel QuickSync not working #5069
Comments
I have created a small Python script which I configured as FFmpeg path in Stash. This script takes the original arguments but removes the This is the script: #!/usr/bin/python
import os
import sys
args=["/usr/bin/ffmpeg"]
i=1
while i < len(sys.argv):
if sys.argv[i] == "-global_quality":
i += 2
else:
args.append(sys.argv[i])
i += 1
os.execv(args[0], args) |
The above actually yields a terrible result / quality. This (probably) as no quality is defined. Using #!/usr/bin/python
import os
import sys
args=["/usr/bin/ffmpeg"]
i=1
while i < len(sys.argv):
if sys.argv[i] == "-global_quality":
args.append("-q")
i += 1
else:
args.append(sys.argv[i])
i += 1
os.execv(args[0], args) Setting a bitrate using And when testing with a 4K video downscaled to 1280x720 the results of both |
Using -q or -qscale is constant quantization which is generally a bad idea for encoding and we shouldn't default to it (even if we use it on vaapi for the lack of a better option). |
@NodudeWasTaken yeah sure. My intention wasn't to push for changing So just reporting the issue, combined with a command which at least does work, and a work-a-round for others which have the same issue. Regarding "introduce more customization for each encoder", I'm not sure if that would be the right path. I can imagine that would become hugely complex and overwelming, while there already are settings to add "input" and "output" flags to ffmpeg commands which users already can use to fine tune the transcoding. And in this specific case it ideally should "just work". Possibly by expanding the implemented encoders with a new one for this scenario. So run a test with QSV + |
@gitgiggety Tried the Python wrapper as ffmpeg path however it keeps reporting file not found even though it's there: If I add a binary file original ffmpeg as ffmpeg_qsv for testing at same location it works without errors. Stash version: v0.26.2-63-ga94bf29b |
Thanks @NodudeWasTaken, just upgraded to 0.27(.0) and it's working fine now, no hack needed anymore 🎉 |
Describe the bug
For me Intel QuickSync support is not working on an Intel N5105 based system. QSV is tested for / used with a combination of options which is not compatible with at least Jasper Lake CPUs. This is due to
-global_quality
being used which leads to a ratecontrol as described here: https://ffmpeg.org/ffmpeg-codecs.html#Ratecontrol-Method This while Jasper Lake CPUs are limited in functionality and seemingly only supports some of those ratecontrol methods.To Reproduce
Steps to reproduce the behavior:
Expected behavior
Startup log message shows that h264_qsv is supported. But instead is just:
While this could/should include h264_qsv and possibly vp9_qsv.
Screenshots
Stash Version: (from Settings -> About):
0.26.2
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context
Trace logs of startup:
Used ffmpeg flags to check QSV support:
Execting ffmpeg with the same flags, except dropping
global_quality 20
executes succesfully.Note:
I haven't tested if there are any other issues yet, but transcoding a 4K video to 1280x720 with a basic command like:
Does show a speed of ~1.75x, and the CPU not being stressed and intel_gpu_top showing that the GPU is fully used (100% "busy" in the "video" engine). While without qsv the CPU maxes all cores at 100% and the speed is below 1 (so playback actually having to wait for the next pieces to be finished).
(But I didn't finish a file and play it back, but I presume it should be working just fine, albeit maybe in a bit lower quality than what it would be if those ratecontrol methods were supported).
The text was updated successfully, but these errors were encountered: