I can think of a few use cases: 1. Desktop - If both implementations run the same but one is faster, you run the faster one to stop the decode spluttering on t

I can think of a few use cases: 1. Desktop - If both implementations run the same but one is faster, you run the faster one to stop the decode spluttering on those borderline cases. 2. Embedded - Where resources are limited, you still go for the faster one, even if it might one day leas to a zero day because you've weighed up the risk and reducing the BOM is an instant win and trying to factor in some unknown code element isn't. 3. Server - You accept media from unknown sources, so you are sandboxed anyway. Losing 5% of computing resources adds up to big $ over a year and at enough scale. At Youtube for example it could be millions of dollars a year of compute doing a decode and then re-encode. Some other resistances: 1. Energy - If you have software being used in many places over the world, that cost saving is significant in terms of energy usage. 2. Already used - If the C implementation is working without issue, there would be high resistance to spend engineering time to put a slower implementation in. 3. Already C/C++ - If you already have a codebase using the same language, why would you now include Rust into your codebase? 4. Bindings - Commonly used libraries use the C version and are slow to change. The default may remain the C version in the likes of ffmpeg.