Deprecate in favor of ffmpeg-static?

[deevus]

As part of becoming a contributor of this package I have looked around for alternatives to see whether it makes sense to continue maintenance of node-ffmpeg-installer. It seems as though https://github.com/eugeneware/ffmpeg-static fulfills the same purpose, already has the means to automatically keep the binaries updated, has more GitHub stars and is actively maintained.

It seems to me that this would be the best course of action.

[deevus]

@kribblo Thoughts?

[deevus]

@derhuerst FYI

[kribblo]

@kribblo Thoughts?

Not so many; I have only had a glance at that project, but if it does the same job equally good or better... in principle, I do not think it makes sense to have duplicate efforts (unless competing for a "best" way).

This project was made with one purpose only, to download only one binary instead of all of them, which all other projects did. But it has its flaws for weirder cases and for updating. I wrote it for the purposes of my former company, but seemed useful enough to release publicly.

Stars I could not care less about :) , but maintenance is good. And focusing in one place, so feel free to do this. For those who only use this for simple wav->ogg it will keep on working anyway, for those with greater needs it would be good.

Forge ahead as you please. :)

[derhuerst]

Hey, maintainer of ffmpeg-static here.

I agree that it makes sense to "merge" the two projects, everything is just wasted effort. I also don't care about which way we do it.

This project was made with one purpose only, to download only one binary instead of all of them, which all other projects did. But it has its flaws for weirder cases and for updating. I wrote it for the purposes of my former company, but seemed useful enough to release publicly.

Yeah, same for ffmpeg-static, it is "just" intended to download a binary.

"Just" downloading a binary is more work than I originally thought, however; Over time, I have

• changed the setup to re-upload ffmpeg binaries to GitHub Releases, for more trustworthiness and not to strain binary providers' hosting.
• added gzip support and conditional requests to save bandwidth (I estimate that ffmpeg-static downloads have caused ~45tb of traffic so far).
• added support for HTTP proxies to help people in enterprisey networks.
• changed it so that it downloads the appropriate readme & license files as well.

Potential enhancements:

• Provide an equally seamless way to get ffprobe & ffplay binaries (provide ffprobe binaries again? eugeneware/ffmpeg-static#19). Currently, this is done via a fork of ffmpeg-static.
• Provide a more transparent and trustworthy source for the binaries, e.g. a build pipeline that cross-compiles all binaries from scratch and uploads them to the GitHub Release.

I'm currently maintaining ffmpeg-static because I see value in having a package like this, but I haven't used it by myself in a while; I'm fine doing the maintenance for now, but I won't commit on more than I'm currently doing. This is also why I haven't built binaries from scratch so far. Maybe we can make our project(s) more sustainable by merging them and cooperating with the maintenance?

[kribblo]

I took a much more simplistic approach, using the built in os and architecture features of node + sub-project dependencies, then I've been downloading binaries from sources listed on the official page and put them in each project and then they just ended up on npmjs.

It's been working well for at least the initial 5 variations, just a little bit of a chore to update now and then, the upload is semi-automated but not the update etc. Could be done.

I'm unlikely to maintain or be involved since I do not personally use it anymore and gradually lost interest. As such, I do not personally mind which of the approaches you guys want to go with, I guess discuss among the active people of both projects and just go with one?

[kribblo]

Also, not totally convinced a cross-compile pipeline is worth the effort to maintain, I guess there's a reason that doesn't already exist out there. Not that I'd stop anyone, but that can be hard work. As long as there are sources trusted by the project i think you should consider leaving it at that, but it's just advice, based on well, knowing how much effort those things can take to keep up :)

[derhuerst]

I took a much more simplistic approach, using the built in os and architecture features of node + sub-project dependencies [...].

Yeah I solved it the same way first, but I didn't like several factors:

• Checking large binaries into Git, I had trouble with the maximum repository size of GitHub.
• Adding all binaries into one npm package is a waste of bandwidth, storage, etc.
• Using one sub-package per OS/arch felt like a weird hack.

[kribblo]

Matter of taste, I guess.

• I have a paid account, maybe that's why repo size was no problem, didn't know it could be an issue.
• It's not one npm package, that's the whole point, and worrying too much about bandwidth or storage is 10 years ago, mostly.
• To be fair, it's the opposite of a hack. It's a built in feature since forever, meant to do stuff like this, but seems few know about it.

With all that said, probably best if those who are going to work with it most and actively pick what they are comfortable with working with :)

[Useems]

Thanks! Using it, solved my problem with NextJS

Module not found: Can't resolve './ROOT/node_modules/@ffmpeg-installer/ffmpeg/node_modules/@ffmpeg-installer/win32-x64/package.json'

./node_modules/@ffmpeg-installer/ffmpeg

Module not found: Can't resolve './ROOT/node_modules/@ffmpeg-installer/ffmpeg/node_modules/@ffmpeg-installer/win32-x64/package.json'
server relative imports are not implemented yet. Please try an import relative to the file you are importing from.

https://nextjs.org/docs/messages/module-not-found