> The safety guarantees being enforced by the compiler does mean that you can (and really should) offload all the checking onto the compiler and not think you know better by casting everywhere etc.

When the set of actions that might violate the guarantees is small, circumscribed and easy to spot in code review and/or with automated tools this kind of approach works. But in C++ it feels more like today's best practices are tomorrow's unsafe constructs - it's like perl's "there is more than one way to do it", but additionally all but one of the ways are unsafe.

> did you not monitor the state of the process you spawned to handle transcoding?

That was my point - we originally tried to use JNI so that we could use libffmpeg as a library (and e.g. handle parameters and input/output as structured data rather than having to flatten them to a string command line and temporary file or pipe). But unfortunately if you do that you give up the nice guarantees of the JVM platform - e.g. a Java-native library will only ever affect its own thread, but a bug in a JNI library can take down the whole JVM. (We did ultimately move to a separate-process-for-transcoding model for exactly this reason)

> Did you end up fixing the bugs in ffmpeg?

We fixed specific bugs as we found them. It didn't feel like we were making a dent in the number there were though.