- You don't trust so much complex logic, taking untrusted input, written in C and want to rewrite it in Rust.

- You want to code it all again using an API that doesn't expect to get its input from a blocking read() function.

- ...

I think the main reason there isn't any alternative is that it supports soooo many formats that the task seems impossible to anybody thinking about it.

> - You want to code it all again using an API that doesn't expect to get its input from a blocking read() function.

In which real world situation/scenario is this a problem? It is hard to think of one, but I am probably missing something?

In any case, if that was a real show-stopper, it would probably be much wiser to go with a fork that would modify that one thing, instead of re-writing the whole project.

I could see it being an issue if you were doing a bunch of streaming transcodes, and wanted that in an event loop instead of blocking... but

a) you're probably going to want to control the number of simultaneous streams to a low enough number that you could just fork

b) the responsible thing to do when decoding streams with ffmpeg is to disable all formats except your whitelisted format, but still sandbox the heck out of it, because there's been a lot of CVEs where a crafted input allows remote code execution

Sandboxing is going to be much more complete if the ffmpeg process is only dealing with one input fd, one output fd (maybe an error reportint fd), and no network or filesystem access --- you don't want a decoder error to influence media you're encoding/decoding for another user.