-
Notifications
You must be signed in to change notification settings - Fork 12
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
Feature request: hwdevice, fallback to cpu on failure instead of throwing an error #64
Comments
This could cause some unexpected behaviour and make it hard to force hardware decoding in cases where you actually want to make sure you're using hardware decoding and error out otherwise (e.g. when debugging something involving hwdec). |
Instead of having to add a 'cuda-safe', 'qsv-save',... option adding an additional parameter i.e. 'fallback: bool, whether to fallback to cpu encoding on error' seems like a better way to go at this. Sure, one could write a wrapper, but personally I think a solution in the filter itself is to be preferred to allow easier usage. |
I'm going to say "wrapper function" mostly for this. |
Sure, the main difference is whether this is implemented once or whether each user has to make sure he uses the wrapper. :) |
hwfallback=true maybe, and note that fallback would only be for the case where no hw decoder exists, not the case that the hw decoder shits itself on decode start |
Sounds good to me, if the decoder should work and crashes it should crash. |
This was more annoying to implement than anticipated. Don't expect it to happen soon. |
Thanks for the update. |
Would be nice if hwdevice would be more like a preference than a force of the device, so that I set by default for example 'cuda' and if the fails, it would fall back to 'cpu'-decoding and only if that fails to, throw an error.
Thanks!
The text was updated successfully, but these errors were encountered: