4 ms·

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 ffmp

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.

CJefferson 3y ago
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.
- deleted 3y ago
  [deleted]
- matsemann 3y ago
  > 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.
oefrha 3y ago
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.
- xcdzvyn 3y ago
  I'm not sure I'd describe FFmpeg's CLI as "too good"
  - Timwi 3y ago
    The parent comment was not referring to the CLI exclusively.
  - oefrha 3y ago
    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.
  - Gormo 3y ago
    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.
- ComodoHacker 3y ago
  So, the next candidate for backdooring? :)
  - SoothingSorbet 3y ago
    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.)
Cyph0n 3y ago
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 https://github.com/aksiksi/needle

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.

CJefferson 3y ago

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.

deleted 3y ago
[deleted]
matsemann 3y ago
> 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.

oefrha 3y ago

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.

xcdzvyn 3y ago
I'm not sure I'd describe FFmpeg's CLI as "too good"
- Timwi 3y ago
  The parent comment was not referring to the CLI exclusively.
- oefrha 3y ago
  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.
- Gormo 3y ago
  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.
ComodoHacker 3y ago
So, the next candidate for backdooring? :)
- SoothingSorbet 3y ago
  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.)

Cyph0n 3y ago

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 https://github.com/aksiksi/needle