3 ms·

Serious question, let's say you had a ton of money and wanted to get this done, is there physically enough available Rust talent (at market rates) in the world

by xnyan 2y ago

Serious question, let's say you had a ton of money and wanted to get this done, is there physically enough available Rust talent (at market rates) in the world today to port ffmpeg to rust in any reasonable amount of time? My understanding is that it's one of the biggest open source projects in terms of LoC, development hours needed to both create and maintain, and number of former and active developers working on the project.

IshKebab 2y ago
There definitely is. You don't need support for all the obscure formats that ffmpeg supports. It would still cost a lot though.
- martinsnow 2y ago
  Perhaps you don't need it. But that doesn't mean a lot of others find them very useful.
- deleted 2y ago
  [deleted]
- tstrimple 2y ago
  If it doesn’t support the formats, it’s not a replacement for ffmpeg. It’s a competitor with fewer capabilities. I’m sure people will flock to that just for the excuse of saying they are using a rust library.
  - IshKebab 2y ago
    > If it doesn’t support the formats, it’s not a replacement for ffmpeg. That's dumb. Like saying a car isn't a replacement for a horse because it can't jump over hedges. Most people do not care about the obscure formats at all. > I’m sure people will flock to that just for the excuse of saying they are using a rust library. Well, for not having to worry about trivial security bugs, yes I suspect they would flock to it! Especially for server side video processing.
    - xnyan 2y ago
      > That's dumb. Like saying a car isn't a replacement for a horse because it can't jump over hedges. A car is not a replacement for a horse, it's a replacement for what was the most common use case of the horse, getting from A->B in a developed environment. There are still (limited) applications where a horse is the best or only transportation option. A pocket knife is not a replacement for a multitool, even if the multitool blade gets used more than any other feature. People use multitools because they want something that can solve multiple problems with a single tool. The greatest feature and the reason people reach for ffmpeg is that it's extremely versatile. If you get rid of that versatility, it's not a replacement for ffmpeg.
      - IshKebab 2y ago
        You can't win by inventing your own overly narrow definition of what "replacement" means. Under your definition nothing is a replacement for anything, which is clearly idiotic.
        martinsnow 2y ago
        He didn't invent his own definition. A drop-in replacement does the exact same thing, as what it would replace in the exact same way. You however don't seem to understand _why_ backwards compatibility is important, and i would absolutely hate to interface with whatever mess of a software you write.
        IshKebab 2y ago
        > A drop-in replacement does the exact same thing, as what it would replace in the exact same way. I agree, but do you see "drop-in" anywhere in my comments? > You however don't seem to understand _why_ backwards compatibility is important I completely understand why backwards compatibility is important. But something doesn't have to be backwards compatible to be a "replacement". I have replaced C++ with Rust in my hobby projects.
        2y ago
Denvercoder9 2y ago
There's plenty of talented developers out there that are currently working in another language, but could relatively quickly learn the required Rust skills to go work on such a project. Domain knowledge (codecs, video/audio processing, etc) is probably a bigger problem.

by xnyan 2y ago

IshKebab 2y ago

There definitely is. You don't need support for all the obscure formats that ffmpeg supports. It would still cost a lot though.

martinsnow 2y ago
Perhaps you don't need it. But that doesn't mean a lot of others find them very useful.
deleted 2y ago
[deleted]
tstrimple 2y ago
If it doesn’t support the formats, it’s not a replacement for ffmpeg. It’s a competitor with fewer capabilities. I’m sure people will flock to that just for the excuse of saying they are using a rust library.
- IshKebab 2y ago
  > If it doesn’t support the formats, it’s not a replacement for ffmpeg. That's dumb. Like saying a car isn't a replacement for a horse because it can't jump over hedges. Most people do not care about the obscure formats at all. > I’m sure people will flock to that just for the excuse of saying they are using a rust library. Well, for not having to worry about trivial security bugs, yes I suspect they would flock to it! Especially for server side video processing.
  - xnyan 2y ago
    > That's dumb. Like saying a car isn't a replacement for a horse because it can't jump over hedges. A car is not a replacement for a horse, it's a replacement for what was the most common use case of the horse, getting from A->B in a developed environment. There are still (limited) applications where a horse is the best or only transportation option. A pocket knife is not a replacement for a multitool, even if the multitool blade gets used more than any other feature. People use multitools because they want something that can solve multiple problems with a single tool. The greatest feature and the reason people reach for ffmpeg is that it's extremely versatile. If you get rid of that versatility, it's not a replacement for ffmpeg.
    - IshKebab 2y ago
      You can't win by inventing your own overly narrow definition of what "replacement" means. Under your definition nothing is a replacement for anything, which is clearly idiotic.
      - martinsnow 2y ago
        He didn't invent his own definition. A drop-in replacement does the exact same thing, as what it would replace in the exact same way. You however don't seem to understand _why_ backwards compatibility is important, and i would absolutely hate to interface with whatever mess of a software you write.
        IshKebab 2y ago
        > A drop-in replacement does the exact same thing, as what it would replace in the exact same way. I agree, but do you see "drop-in" anywhere in my comments? > You however don't seem to understand _why_ backwards compatibility is important I completely understand why backwards compatibility is important. But something doesn't have to be backwards compatible to be a "replacement". I have replaced C++ with Rust in my hobby projects.
        2y ago

Denvercoder9 2y ago

There's plenty of talented developers out there that are currently working in another language, but could relatively quickly learn the required Rust skills to go work on such a project. Domain knowledge (codecs, video/audio processing, etc) is probably a bigger problem.