Retiring the repository

[nihil-admirari]

@pukkandan, the last remaining FFmpeg patch was merged to FFmpeg master yesterday: FFmpeg/FFmpeg@b76053d.

That patch is still applicable to 7.1 release, but there are no others. Once a new FFmpeg release is made, there'll be no point in having this repository.

If new patches are added, the repository can be resurrected.

[pukkandan]

Let me know when that happens. We can add a note to readme and archive the repo

PS: Thanks for everything you've done for this!

[gamer191]

Once a new FFmpeg release is made, there'll be no point in having this repository.

Does FFmpeg 7.1.1 include the fix? (EDIT: If not, line 59 of the readme should probably be updated)

Thanks for everything you've done for this repo! If, and only if, you wish to continue to maintain this, I might go through the yt-dlp external issues list to see if there's any more patches that should be added to this repo (I've been meaning to do that for a while but I keep forgetting)?

EDIT: before archiving the repo, https://trac.ffmpeg.org/ticket/7673 should probably be added to "patches welcome"

[nihil-admirari]

If not, line 59 of the readme should probably be updated

Fixed.

EDIT: before archiving the repo, https://trac.ffmpeg.org/ticket/7673 should probably be added to "patches welcome"

Added.

[God-damnit-all]

Rather than archiving, it might be better to simply halt the workflows, remove the releases, and say the repo is retired. That way a PR can be submitted for the patches that are welcome, as well as allowing a new issue to be posted if there's something that was overlooked.

[gamer191]

If new patches are added, the repository can be resurrected.

I intend to submit a bug report to FFmpeg and write a patch for yt-dlp/yt-dlp#12495 very soon (probably tomorrow). So unfortunately I think this repo will need to stay for a little while longer

(I’m aware that the issue could be fixed by passing the -allowed_extensions CLI option to FFmpeg, but Bashonly and I have collectively decided against that, on the basis that maintaining a list of allowed_extensions to pass to FFmpeg is not sustainable, and potentially a security risk)

[God-damnit-all]

If new patches are added, the repository can be resurrected.

I intend to submit a bug report to FFmpeg and write a patch for yt-dlp/yt-dlp#12495 very soon (probably tomorrow). So unfortunately I think this repo will need to stay for a little while longer

(I’m aware that the issue could be fixed by passing the -allowed_extensions CLI option to FFmpeg, but Bashonly and I have collectively decided against that, on the basis that maintaining a list of allowed_extensions to pass to FFmpeg is not sustainable, and potentially a security risk)

How's the progress on this coming?

[gamer191]

Oops, I completely forgot about this. Anyway, FFmpeg seem to have merged a fix themselves: FFmpeg/FFmpeg@2352145. Can we add that to this repo as a release-only patch?

EDIT: nevermind, that patch doesn't fix yt-dlp/yt-dlp#12495

[gamer191]

Here's another ffmpeg commit that should be backported to 7.1 (I'll make a PR next time I remember about it lol) FFmpeg/FFmpeg@48c0dba

[God-damnit-all]

Here's another ffmpeg commit that should be backported to 7.1 (I'll make a PR next time I remember about it lol) FFmpeg/FFmpeg@48c0dba

Don't forget to remember! 😛

[nihil-admirari]

Backported FFmpeg/FFmpeg@48c0dba to 7.1.

[gamer191]

Backported FFmpeg/FFmpeg@48c0dba to 7.1.

Thanks

Apologies, I forgot to mention that the relevant yt-dlp issue is yt-dlp/yt-dlp#12741. Up to you whether to update the readme (I don't think it's worth me making a PR, given it would cause conflict hell next time the rebase on upstream action runs?)

[lrstanley]

If new patches are added, the repository can be resurrected.

Rather than archiving, it might be better to simply halt the workflows, remove the releases, and say the repo is retired. That way a PR can be submitted for the patches that are welcome, as well as allowing a new issue to be posted if there's something that was overlooked.

I have a library that auto-downloads/installs yt-dlp (paired with cli bindings for that specific version), and I'd like to add ffmpeg capabilities to that list, however, I'd like to pick a source that is going to have updated ffmpeg builds. I'd prefer a solution that has versions of ffmpeg I know should always work with yt-dlp, however, if the plan is to spin up and down the repo based on some patches being needed for some builds, it makes it difficult to have a stable source.

Thoughts on continuing to let workflows/builds/etc run, even when there are no patches, so there is a reliable place to pull binaries from? In the situations where there are no patches, I assume that it would just constantly pull from upstream and no changes would be needed (and thus theoretically, little effort to maintain).

[kitsumed]

Im in the same similar situation as @lrstanley . One of my project release CLI also relies on the builds from this repo during packaging.

That said, if you do plan to discontinue it after all issues are merged into the main repo, I could switch to using BtbN/FFmpeg-Builds. However, unless we start building them ourselves making packaging longer, we will lose win x32 support (as BtbN does not build for win x32). Which isn't a huge loss, but still worth a mention.