Why should anyone install this over default Ffmpeg?

[Sepero]

I found this post on Reddit.

https://www.reddit.com/r/jellyfin/comments/12tijk6/comment/jh71qxz/

Perhaps you could list at the top of the README differences between jellyfin-ffmpeg and default ffmpeg. And perhaps add a few scenarios where someone may prefer to use jellyfin-ffmpeg.

[gnattu]

At this point the default upstream ffmpeg (7.0) branch would break most if not all hardware acceleration pipeline used in Jellyfin. Even for users don't need hardware acceleration at all or have no intention to do any kind of transcoding, this fork also contains some Dolby Vision fixes for HLS which is still useful.

[Sepero]

At this point the default upstream ffmpeg (7.0) branch would break most if not all hardware acceleration pipeline used in Jellyfin. Even for users don't need hardware acceleration at all or have no intention to do any kind of transcoding, this fork also contains some Dolby Vision fixes for HLS which is still useful.

Request to post this at the top of the README so that others can make an informed decision on whether or not to install.

[gnattu]

We do not really modify the upstream README directly, but I wrote a brief summary in the wiki page:

https://github.com/jellyfin/jellyfin-ffmpeg/wiki

[pyorot]

Apologies if this is irrelevant (I didn’t want to start an issue to ask a question). I am curious on what the current situation is in submitting the custom patches back upstream, whether it happens, why or why not, etc.

[gnattu]

I am curious on what the current situation is in submitting the custom patches back upstream, whether it happens, why or why not, etc.

Basically we gave up most efforts upstreaming feature patches. Bug fixes will still be upstreamed if the upstream accepts that, for example #439 and #433. The upstream has a very different development focus which makes it hard to upstream new features, especially hardware-specific features now. It might get ignored for months or even forever without review. Some of our features are implemented in a way that some upstream maintainers have strong opinion against like our software tonemapx filter, which uses simd intrinsics heavily. Upstream also care about the platforms that we do not care about like ancient processors, compilers and OS versions. They have to guarantee the build does not break on those platform but we don't have to, and requiring us to spend time fixing the platforms we don't really use is also too much hassle.

[Sepero]

Perhaps it may be more desirable to prefer this fork in all scenarios..

Would it be accurate to say that this fork of ffmpeg has all the abilities of upstream plus more?

[gnattu]

Perhaps it may be more desirable to prefer this fork in all scenarios..

Would it be accurate to say that this fork of ffmpeg has all the abilities of upstream plus more?

We've made some changes that result in different behavior compared to the upstream version, and not all of them may be ideal for every use case. For instance, we may revoke certain upstream changes or remove upstream features for specific hardware due to compatibility or performance concerns. However, we're not entirely sure whether the upstream implementation or our version will work better for your specific use case. However, if you find some of the features in our fork useful, you're welcome to use this fork outside of Jellyfin as well.

[Sepero]

Would it be accurate to say that this fork of ffmpeg has all the abilities of upstream plus more?

So the current answer to this seems to be "not really". But if the answer ever changes to "mostly yes", then please post here and make an announcement. I and many others would be very interested to put it to the test. We could report to Phoronix for benchmarks.

[gnattu]

So the current answer to this seems to be "not really". But if the answer ever changes to "mostly yes", then please post here and make an announcement.

Depends on how you draw the line, it could be "not really" or "mostly yes". Can you let me know which specific features you're interested in, so I can give you a concrete answer? This fork reverts or removes upstream features very little but adds much more. Of course, we will be lag behind in version numbers by a few months to wait for regression fixes and do our own migration.

I and many others would be very interested to put it to the test. We could report to Phoronix for benchmarks.

We do provide pre-built statically linked binaries so you can test if it works for your use case right now. If you don't use post processing filters the performance difference may not be that obvious as those will be mostly hardware performance limited.

[Sepero]

Then perhaps the answer is "mostly yes"?

99% of people have no need for the bleeding-edge version of ffmpeg, so being behind a couple months doesn't really matter.

I think the most relevant question to answer for everyone would be, what specific features have been reverted or removed? (And perhaps why?)

If someone doesn't need those reverted/removed features, then using this fork would seem the obviously preferable choice over standard ffmpeg.

If done correctly, this jellyfin-ffmpeg fork has the potential to become more popular than the upstream, just like yt-dlp has become more popular than it's upstream (yt-dl).