ffmpeg-build-script VS homebrew-core

Are there any plans to update agentdvr to support ffmpeg-shared builds v6? The ffmpeg build script for linux uses a modified version of this script https://github.com/markus-perl/ffmpeg-build-script Looks like he made a recent one with ffmpeg 6.0 support(v1.44)

It's straightforward to compile ffmpeg with libfdk_aac support to be sure quality remains high, especially e.g. build scripts.

After quite a bit of searching around I was unable to find a simple way of getting a build of FFMPEG with all the different AV1 encoders, and building manually would mean I'd have to go get all the libraries that are enabled by default in say, Ubuntu's FFMPEG repo. So I took it into my own hands and modified this build script and added rav1e to the build in my fork here.

install of ffmpeg. I've started using github.com/markus-perl/ffmpeg-build-script because, why re-invent the wheel

I'm currently using this build script so that I can use svt-av1, but I wan't to give rav1e a shot and it's not included. Does anyone know of somewhere I can get ffmpeg compiled with rav1e, or a relatively simple way to do it myself with all the other codecs that build script supports?

These days the situation is much better, but you really want FDK-AAC for best quality (it's proper Fraunhofer code released as Open Source for the Android project, and now widely compatible on all platforms). You can find a standalone front end in the repos, but I prefer to build ffmpeg with support for it for more flexibility. (The ffmpeg built in default aac encoder is still noticeably worse, despite it's improvement a few years ago.)

$ brew info eza ==> eza: stable 0.18.13 (bottled) Modern, maintained replacement for ls https://github.com/eza-community/eza Not installed From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/e/eza.rb License: MIT ==> Dependencies Build: pandoc ✘, pkg-config ✔, rust ✘ Required: libgit2 ✘ ==> Analytics install: 12,792 (30 days), 38,295 (90 days), 68,375 (365 days) install-on-request: 12,790 (30 days), 38,293 (90 days), 68,375 (365 days) build-error: 0 (30 days)

Is disabling the compromised repo the typical GitHub policy? My concern is there are monorepos used by package managers, like brew, that are a collection of thousands of projects [1]. These monorepos seem like a prime target for attack and if GitHub disables one because a malicious commit was merged then you've taken down an entire ecosystem.

[1] https://github.com/Homebrew/homebrew-core

> Correct. Though we do not appear to be affected, this revert was done out of an abundance of caution.

[1] https://github.com/Homebrew/homebrew-core/pull/167512

> right, but now you know even less about your setup when you some roadblock

This is the same with a binary though. And with homebrew, you can't follow patches or flags used or if they change.

- https://github.com/Homebrew/homebrew-core/blob/c964ad7fa53ad...

definitely be careful about using fortune in a corporate environment or public space if you don't know what dat files you are using or you might just get an extremely unwelcome surprise.

I was practicing a presentation and used to use "fortune" all the time. I forget exactly what it output but I remember being absolutely mortified about what could have happened if that had popped up during an internal company tech talk.

Kudos to brew for keeping unsuspecting people safe

https://github.com/Homebrew/homebrew-core/commit/3fb3c4c3e55...

I'm sorry to be asking this as I find it a bit silly, but it's blocking my PR [3], so could a few of you star the project on Github [1] to get my PR to run?

[1] https://github.com/laktak/chkbit-py

[2] https://brew.sh

[3] https://github.com/Homebrew/homebrew-core/pull/160018