Skip to content
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

Open
Selur opened this issue Sep 7, 2024 · 8 comments

Comments

@Selur
Copy link

Selur commented Sep 7, 2024

hwdevice: The interface to use for hardware decoding. Depends on OS and hardware. On windows d3d11va, cuda and vulkan (H264, HEVC and AV1) are probably the ones most likely to work. Defaults to CPU decoding. Will throw errors for formats where hardware decoding isn't possible.

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!

@arch1t3cht
Copy link
Contributor

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).
IMO this would be better handled with a simple python wrapper function.
Alternatively, there could be additional options like cuda-safe to opt in to falling back to cpu decoding, but a wrapper sounds more sensible to me.

@Selur
Copy link
Author

Selur commented Sep 7, 2024

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.

@myrsloik
Copy link
Member

myrsloik commented Sep 7, 2024

I'm going to say "wrapper function" mostly for this.
I suppose for formats where no hw decoder exists for the selected format it could use a fallback to cpu but internally it would literally be the same as a wrapper function.

@Selur
Copy link
Author

Selur commented Sep 7, 2024

Sure, the main difference is whether this is implemented once or whether each user has to make sure he uses the wrapper. :)
So would be nice if this could be added. :D

@myrsloik
Copy link
Member

myrsloik commented Sep 7, 2024

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
I'll think about it

@Selur
Copy link
Author

Selur commented Sep 7, 2024

Sounds good to me, if the decoder should work and crashes it should crash.
If no decode i.e. ProRes, Huffyuv,... exists falling back to cpu sound good.

@myrsloik
Copy link
Member

This was more annoying to implement than anticipated. Don't expect it to happen soon.

@Selur
Copy link
Author

Selur commented Oct 19, 2024

Thanks for the update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants