Hacker News Reader

Hacker News

Comment by metadat | Hacker News Reader

Parent Full thread

metadat

At first I thought this was a full rewrite in Rust, but it's not

Why would one want a "Safe FFMpeg Wrapper"?

Edit: Got it, provides a rust API library to ffmpeg. Thanks @CJefferson.

View on HN

I use it — because I am writing a rust program, and want to use ffmpeg functionality.

What’s the alternative? I could wrap the C API, and then try to make a nice rust interface from that, but then that’s exactly what this package does, so I don’t want to repeat the work.

> What’s the alternative?

I often just exec ffmpeg from whatever language I'm using (as a command line thing). Not very ergonomic, but the nice thing is that it's 1:1 with all examples and other uses of ffmpeg. But I guess it depends on how deep into ffmpeg you're doing stuff. Mine is mostly to point it at doing something non advanced with a file and that's it.

Basically no one rewrites FFmpeg in recent years, in any language, at least not in the open source scene (and judging from the known usage of FFmpeg in world’s premier providers of multimedia content, probably not in the commercial scene either). It’s both too good and too daunting.

So, the next candidate for backdooring? :)

Bah, don't give them ideas! Honestly, codecs are a worrying target for supply chain attacks because they're complex and use a lot of memory-unsafe code. Just look at all the image format attacks throughout history (a memorable recent one being the libwebp vulnerability.)

I'm not sure I'd describe FFmpeg's CLI as "too good"

The parent comment was not referring to the CLI exclusively.

I’m talking about the underlying libav*. There are plenty of frontends in all sorts of languages, although ffmpeg(1) itself is obviously the most versatile. Also, CLI UX is highly subjective (hence all the different frontends by people with differing opinions), I personally find it more than acceptable for the immense complexity it encapsulates.

I'd say the fact that I can pass in multiple input sources, apply a complex chain of filters, set detailed rendering options, set output parameters, and have it all work flawlessly, and do all of the above in a single command line with consistent syntax, makes "too good" a very accurate description of the FFMpeg CLI.

I used this wrapper to implement an opening and ending detection tool for “fun” [1].

However, it seems that many programs opt to instead shell out to the ffmpeg CLI. I think it’s usually simpler than linking against the library and to avoid licensing issues. But there are some cases where the CLI doesn’t cut it.

[1] https://github.com/aksiksi/needle

Reply on news.ycombinator.com