Skip to content

Commit

Permalink
build: require our own ffmpeg repo
Browse files Browse the repository at this point in the history
This is required now. Can't have FFmpeg upstream randomly break us and
then not fix it (like this recent EOF issue).

Upstream FFmpeg is of course still supported, but you will need to edit
the build scripts. Official support is only with the master branch of
our own repo.
  • Loading branch information
wm4 committed Oct 27, 2017
1 parent f36d152 commit 83d44ac
Showing 1 changed file with 11 additions and 3 deletions.
14 changes: 11 additions & 3 deletions wscript
Expand Up @@ -462,12 +462,18 @@ libav_dependencies = [
'req': True,
'fmsg': "FFmpeg/Libav development files not found.",
}, {
'name': 'is_ffmpeg',
'desc': 'libav* is FFmpeg',
'name': 'is_ffmpeg_garbage',
'desc': 'libav* is upstream FFmpeg (unsupported)',
# FFmpeg <=> LIBAVUTIL_VERSION_MICRO>=100
'func': check_statement('libavcodec/version.h',
'int x[LIBAVCODEC_VERSION_MICRO >= 100 ? 1 : -1]',
use='libavcodec')
}, {
'name': 'is_ffmpeg',
'desc': 'libav* is FFmpeg mpv modified version',
'func': check_statement('libavcodec/version.h',
'int x[LIBAVCODEC_MPV ? 1 : -1]',
use='libavcodec')
}, {
# This check should always result in the opposite of is_ffmpeg.
# Run it to make sure is_ffmpeg didn't fail for some other reason than
Expand All @@ -485,7 +491,9 @@ libav_dependencies = [
'func': check_ffmpeg_or_libav_versions(),
'req': True,
'fmsg': "Unable to find development files for some of the required \
FFmpeg/Libav libraries. You need at least {0}. Aborting.".format(libav_versions_string)
FFmpeg/Libav libraries. You need at least {0}. For FFmpeg, the mpv fork, that \
might contain additional fixes and features is required. It is available on \
https://github.com/mpv-player/ffmpeg-mpv Aborting.".format(libav_versions_string)
}, {
'name': '--libavdevice',
'desc': 'libavdevice',
Expand Down

51 comments on commit 83d44ac

@dtl131
Copy link

@dtl131 dtl131 commented on 83d44ac Oct 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really?

@myfreeer
Copy link
Contributor

@myfreeer myfreeer commented on 83d44ac Oct 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has broken appveyor continuous integration.

@Earnestly
Copy link

@Earnestly Earnestly commented on 83d44ac Oct 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be worked around by exporting CPPFLAGS=-DLIBAVCODEC_MPV=1 before ./waf configure

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Oct 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a really terrible idea...on all fronts.

@niko-yanev
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely this is a very, very bad idea guys, especially on kde, mostly, but not only...
think about reverting. I am using mpv-git for years and never saw a breakage with the upstream ffmpeg. Also git version is always up-to-date at my manjaro repo and i've modified the script, to work with the upstream ffmpeg, but i am thinking of dropping support soon if you don't revert to official, but not mpv version of ffmpeg.
Thanks

@niko-yanev
Copy link

@niko-yanev niko-yanev commented on 83d44ac Oct 29, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sure that if the mpv guys don't revert it, sooner or later the distros will start dropping support. Or there will be another movie fork following ffmpeg master.

@CounterPillow
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what it's worth, mpv doesn't and has rarely cared about downstream, usually because downstream doesn't care about mpv (and goes out of their way to patch out mpv warnings about broken downstream builds.)

Just let wm4 have his ragefork for a week or two, it'll likely be back to normal once the next mpv release is made. It's not like Debian et al will update mpv or ffmpeg in the next few years anyway.

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Oct 29, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not all distros are so outdated as debian. The SlackBuild maintainer follows the latest release well for example. Anyways, I submitted a PR to revert this inanity here. #5056

@Hrxn
Copy link
Contributor

@Hrxn Hrxn commented on 83d44ac Oct 29, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not like Debian et al will update mpv or ffmpeg in the next few years anyway.

🀣
True, true

@eli-schwartz
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

downstream doesn't care about mpv (and goes out of their way to patch out mpv warnings about broken downstream builds.)

s/warnings/errors/;s/broken/maybe-broken/

Some downstreams, maybe. Arch certainly does no such thing, though we also don't ship FrankenPackages...
But I suppose forking ffmpeg isn't so different from adding in angry error messages that are only relevant for the distro that patches it out anyway.

@eli-schwartz
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's very different from making it difficult to build against the (fixed) system version anyway without patching the MPV sources...

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Oct 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with that logic is no distro is going to support your ffmpeg fork and this can end in only three ways.

  1. People continue to use upstream ffmpeg usually without any issue.
  2. Mpv fades into obscurity never to be used.
  3. A new fork with far nicer and more reasonable devs emerges.

@shinchiro
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you insist avoiding mpv's ffmpeg fork, you can just tell the maintainer to apply the additional patches on top of original ffmpeg. That will solve your problem.

@eli-schwartz
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't see the problem anyway. ffmpeg has a terrible habit of making backwards-incompatible changes without warning, but these are things that mpv will ultimately be changing anyway. Or if ffmpeg has a legitimate bug rather than a political decision to avoid proper deprecation policies, ffmpeg will fix that anyway, too.

There are two types of distro downstream maintainers: the type that keeps on top of these things, and the type that doesn't. Both of them will be using the system ffmpeg regardless, and the only difference is whether mpv makes that difficult or easy.

Why punish the distros that do it right, and cherry-pick upstream fixes as needed, in order to mess with the distros that don't do it right, and don't care about mpv's threats since they will patch it out anyway?

@haasn
Copy link
Member

@haasn haasn commented on 83d44ac Oct 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to remind everybody that programs like Firefox and Chromium ship their own versions of not only ffmpeg but pretty much every other dependency (libjpeg, sqlite, libvpx, ffmpeg, etc.).

Clearly distroers are fine with in-tree copies of dependencies, and in fact Firefox in particular actively breaks if you use e.g. system-wide libjpeg instead of its own version (renders all JPEGs with color channels inverted). mpv is hardly the own program that requires its own versions of dependencies.

That being said, firefox and chromium handle this better than mpv: instead of requiring the distro to ship mpv-patched ffmpeg system-wide, they actually incorporate it into the source tree itself and build it using the native build system as part of the compile process. This makes it easy for distroers to handle this, inasmuch as they literally don't even notice the difference. (The exception being distros like gentoo which go out of their way to allow you to use system-wide dependencies instead of bundled ones)

@ArchangeGabriel
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Distros don’t like in-tree copies of dependencies, at least not some of them. On ArchLinux, we try to use system libs as much as possible, see that for Chromium we try hard even if we don’t build with system ffmpeg currently but that we use system ffmpeg for Firefox. Yes, they are still embedded libs in Firefox and Chromium, but the hope is for them to go away at some point.

Our most β€œhardcore” package in this regard is, I believe, electron.

I think Debian is even more strict about those things than we are.

@Earnestly
Copy link

@Earnestly Earnestly commented on 83d44ac Oct 30, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ArchangeGabriel Holy hell, those are crazy. My sympathies to any maintainer who has to deal with that garbage

@CounterPillow
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought part of mpv's way of cleaning up mplayer's act was to stop including an internal source copy of ffmpeg?

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Oct 31, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@haasn The biggest mistake in that argument is that by no means is what chromium or mozilla doing at all acceptable. The only reason they have succeeded at all is because they have a significant financial advantage and the alternatives are either worse or far too underdeveloped.

Its an extreme shame that people like @wm4 are so unfriendly to both upstream and downstream projects alike, it does not foster a good community and can only alienate the people who made mpv so popular in the first place, the users.

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Nov 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eli-schwartz
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to remind everybody that programs like Firefox and Chromium ship their own versions of not only ffmpeg but pretty much every other dependency (libjpeg, sqlite, libvpx, ffmpeg, etc.).

Clearly distroers are fine with in-tree copies of dependencies, and in fact Firefox in particular actively breaks if you use e.g. system-wide libjpeg instead of its own version (renders all JPEGs with color channels inverted). mpv is hardly the own program that requires its own versions of dependencies.

The logical fallacy here is rather astounding. Because large upstream projects do so, therefore downstream packagers approve?

And of course on top of that you can have confirmation, for free, that distros as a rule hate it and are driven crazy by it, and aggressively try to debundle those dependencies whenever possible. Fortunately, Firefox is developed by people who are friendly and helpful, and offer numerous --enable-system-x flags which downstreams gratefully use (except when Firefox breaks something and internal libs must be temporarily enabled, but we try to switch back when we can).

(The exception being distros like gentoo which go out of their way to allow you to use system-wide dependencies instead of bundled ones)

It is the rule, not the exception...

@Kagami
Copy link
Contributor

@Kagami Kagami commented on 83d44ac Nov 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that distros as a rule hate it and are driven crazy by it

Not so much like you're trying to present. Here is doc regarding static linking in Debian: https://wiki.debian.org/StaticLinking
As you can see, in languages like Haskell/OCaml/Go you have to statically link all dependencies into the final binary and everybody is fine with it.

Distros are trying to dictate rules to upstream but don't even trying to understand why upstream doesn't want to use those great already packaged deps. Obviously for wm4 it's easier to fork than trying to pleasure distros while using deps he can't control the way he wants.

@monarc99
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Distros only use mpv release versions. Only the releases need to be compatible against ffmpeg/master or ffmpeg releases.

ffmpeg-mpv is ffmpeg/master (merge) with a few patches for mpv?
If you release a new mpv version, make sure that all patches are upstream und switch to ffmpeg/master in the release branch.

You can develop mpv with your ffmpeg-mpv (without breaks from upstream), only for releases you need to do the work for upstream.

@Hrxn
Copy link
Contributor

@Hrxn Hrxn commented on 83d44ac Nov 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Distros only use mpv release versions. [..]

Yeah, but release versions from when? This century?

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Nov 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wm4 Distros like debian that intentionally use outdated software should be expected to backport fixes themselves, there is no need to go out of your way to please them. That said other distros do not have this issue and do use up to date ffmpeg and mpv releases, some of these even have optional builds or build scripts to create packages from the git master. You;re just making them hard to support your efforts and scaring away future potential contributors in the process.

@eli-schwartz
Copy link

@eli-schwartz eli-schwartz commented on 83d44ac Nov 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not so much like you're trying to present. Here is doc regarding static linking in Debian: https://wiki.debian.org/StaticLinking
As you can see, in languages like Haskell/OCaml/Go you have to statically link all dependencies into the final binary and everybody is fine with it.

No, they say it is "allowed", and imply that you might want to rethink doing so...

And some languages simply don't support dynamic linking. At all. Either because the golang compiler doesn't really support dynamic linking at all, or because haskell dynamic linking is a hot mess (Arch Linux currently builds haskell libs dynamically, but it requires rebuilding all packages anyway because there is no stable ABI, and the tools don't support dynamic-by-default). I don't know about ocaml.
Debi
If it is literally impossible, sure, distros are "fine" with it. After all, we are "fine" with certain vendored libraries in Firefox/Chromium as well (since we have no choice).

Indeed, I don't see any reason to go through extra effort just to pleasure Debian.

But that's not what's happening here. Instead, you are going through extra effort just to annoy Debian. And catching every other distro in the crossfire. 😒

Yeah, but release versions from when? This century?

Ancient distros that ship ancient versions of mpv, will most likely also ship ancient versions of ffmpeg. You don't have to worry about them, just close any bugs they report as "we don't support ancient versions of mpv or ffmpeg".

But anyways, no one expects mpv to bend over backwards to support ancient versions of itself. I'd argue that expecting mpv to support ancient versions of ffmpeg is madness as well, but the README does say "The main reason mpv still builds with older FFmpeg versions is to evade arguing with people (users, distros) who insist on using older FFmpeg versions for no rational reason."

Considering the aggressive attitude mpv has towards Debian and their habit of ancient software releases, I would say a much healthier policy would be to close all Debian bugreports as -EDEBIAN. Quite frankly, Debian is aware of their activity and does this deliberately, and they justify their policy by strongly encouraging their users to report issues only to the Debian bugtracker and allow maintainers to bring things upstream if necessary... you should respect their policy. 😁

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Nov 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wm4 I would like to thank you for your recent commit making its more configurable. I do not expect mpv master and ffmpeg master to always build, what I do expect is for community that is receptive to fixing and working around these issues as they arise. I also agree that ffmpeg is less than ideal at times, but a fork that conflicts with upstream is not a good solution. The way I see it there are a few good options.

  1. Work with upstream ffmpeg to fix their flaws.
  2. Entirely remove the libav/ffmpeg dependency. This could be done by entirely baking in the required components of ffmpeg and adapting them as needed or coming up with a new library that does not conflict with upstream ffmpeg and the countless programs that rely on it.

I think you are in the best position to tell how feasible choice 2 is. If you want to continue your shallow ffmpeg-mpv fork the only thing I ask is that you please find a method to work with upstream ffmpeg to implement your improvements over time.

@olifre
Copy link
Member

@olifre olifre commented on 83d44ac Nov 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to continue your shallow ffmpeg-mpv fork the only thing I ask is that you please find a method to work with upstream ffmpeg to implement your improvements over time.

I think that's already what @wm4 is actively doing. All the things changed in the ffmpeg-mpv fork are, as far as I know, already submitted for inclusion to upstream ffmpeg.
The main issue is that ffmpeg takes quite a while to implement those fixes. If they would be faster, and not break ABI all too often, I guess this situation would never have come up.

So yes, I totally follow - if ffmpeg takes too long for essential fixes and essentially blocks mpv development, the only reasonable way to go is to provide a "patchset" needed to make ffmpeg compatible.
Doing that in form of a ffmpeg-mpv repo sounds reasonable and comfortable. It also allows distros staying up to date to actually use a recent ffmpeg version with all their packages, including mpv.

Alternatively, the distro can still decide to package ffmpeg-mpv separately, depending on what their policies are. To give an example:
https://bugs.gentoo.org/show_bug.cgi?id=635650
On the Gentoo bugtracker, there are now packages for mpv and ffmpeg-mpv, and my hope is they might offer both in the future so the users can choose whether to use ffmpeg-mpv + mpv (from git) or upstream ffmpeg with mpv (at their own risk).

@haasn
Copy link
Member

@haasn haasn commented on 83d44ac Nov 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main issue is that ffmpeg takes quite a while to implement those fixes. If they would be faster, and not break ABI all too often, I guess this situation would never have come up.

Keep in mind the reason mpv was forked from mplayer2 is because mplayer2 took too long to incorporate changes, opposed removing bad/unmaintained code, or rejected patches for no real reason. We see all of the same in FFmpeg. Part of the reason why mpv was able to become so popular to begin with was because it was forked. Much of the arguments against ffmpeg-mpv would also go against mpv at the time of its creation; so it's sort of hypocritical to be opposing it on those grounds alone.

@Earnestly
Copy link

@Earnestly Earnestly commented on 83d44ac Nov 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor changes? For me it produced libavformat with a soname bump from .57 to .58. Because this required every dependency to be relinked I can't reasonably use ffmpeg-mpv as a replacement for upstream ffmpeg at the moment :(

This is a minor issue but it means I will have to fall back on a normal release of mpv (and ffmpeg) for the time being. As a result this somewhat prevents me from submitting any bug reports.

On a bit of a tangent, have you considered copying only (operative word, I know) the needful code from ffmpeg directly into mpv's codebase?

@Earnestly
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Nov 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@haasn The difference between forking mplayer2 or even mplayer and ffmpeg is that any user trivially can choose to use mplayer, mplayer2 or mpv without causing disruptive incompatibilities with their system. Ffmpeg however is used by countless other programs and you can't just replace it with libav or another fork. There are reasons why distros like Debian and Slackware no longer provide libav and only offer ffmpeg.

(github doesn't let me edit comments, just delete and resubmit...)

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Nov 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also breaking support for release versions of ffmpeg is yet another nail in the coffin...

Checking for Libav/FFmpeg library versions                           : no ('libavutil >= 56.0.100 libavcodec >= 58.2.100 libavformat >= 58.0.102 libswscale >= 5.0.101 libavfilter >= 7.0.101 libswresample >= 3.0.100' not found) 
Unable to find development files for some of the required FFmpeg/Libav libraries. You need git master. For FFmpeg, the mpv fork, that might contain additional fixes and features is required. It is available on https://github.com/mpv-player/ffmpeg-mpv Aborting.

ffmpeg-3.4-x86_64-1_SBo

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Nov 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just sad that you made something actually good, but then constantly found ways to reduce useful functionality or accessibility. This is by far not the first case and if you really insist I could come up with a whole laundry list. Mpv's biggest bug is your attitude, not your technical merits. My preferred outcome is that you become someone others can work with.

@CounterPillow
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@orbea your criticism of wm4 is more warranted for Michael Niedermayer, who caused this in the first place.

@mia-0
Copy link
Member

@mia-0 mia-0 commented on 83d44ac Nov 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, ffmpeg-mpv can be installed alongside the release version of the ffmpeg libraries without causing any conflicts. All the soversions are different so nothing will have to be recompiled.

This is mostly a distro problem, and one that affects many other projects to the point that they’re all coming up with different, incompatible app bundles which don’t even solve the basic problem (and, at the moment, none of them work reliably either). Not moving with upstream on a non-enterprise desktop system is extremely unfriendly to users. Yes, you can do this while still trying hard to ensure a coherent system, but so far I’ve seen only one distro actually pull that off successfully. This has to change. Distributors need to adapt to the accelerating pace of software development which is unlike what we’ve seen 15 years ago when Debian could still be taken seriously.

Anyway, I’ll try to time the next release so that it works with FFmpeg master, and distros will just have to package that then (until a compatible release rolls around). This should not be a problem.

@Hrxn
Copy link
Contributor

@Hrxn Hrxn commented on 83d44ac Nov 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you can do this while still trying hard to ensure a coherent system, but so far I’ve seen only one distro actually pull that off successfully.

Which one, if I may inquire?

@Earnestly
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lachs0r While I fully agree, I think there should be a point made about following the latest upstream releases (for whatever definition upstream gives to their releases) compared with requiring downstream follow the latest developmental code.

@mia-0
Copy link
Member

@mia-0 mia-0 commented on 83d44ac Nov 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes of course. FFmpeg still is kind of a special case though because project dependencies are all over the place due to frequent API/ABI breakage, so distros will have to build multiple versions anyway (openSUSE Tumbleweed, the distro I was referring to earlier, does this as well). In practice, distros can’t just dictate a single version to be used for all packages. They’re forced to yield some control to the developers. And FFmpeg should take the blame for this mismanagement, not mpv.

@richardpl
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What a pile of trash.

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Nov 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@CounterPillow. Michael Niedermayer didn't start this nor was he ever unreasonable or rude in the mailing lists posts where he rejected wm4's patches. He also didn't throw a tantrum at the result. You will just have to accept that this bad attitude at the head of mpv development is not sustainable or welcoming. It will only hurt mpv in the long run. You should try to think for yourself instead of fighting other people's losing battles.

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Nov 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lachs0r I know no other project short of possibly insane web browsers that would refuse to fix their code to work with latest ffmpeg releases. I certainly don't know any projects that would not only refuse to do this, but actively went out of their way to break support out of spite.

@Hrxn
Copy link
Contributor

@Hrxn Hrxn commented on 83d44ac Nov 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it's certainly beneficial if you can get your apps from the package system of your distro. It's easier, more comfortable, and you avoid potential problems in the future by keeping consistency. That said, I don't really get it either. Users should always know the fundamentals of how their system works, in my opinion.
And I actually think that distros are part of the problem. I mean, just go to DistroWatch and look at that monstrosity of a list for yourself. Textbook example of the forking problem.

@olifre
Copy link
Member

@olifre olifre commented on 83d44ac Nov 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though I'd say we are at the wrong place here to discuss that...

Using packages from the distro has (at least) the following advantages:

  • The distro takes care to apply and backport security fixes. This is usually not done for library versions bundled with packages downloaded from somewhere, unless you take care yourself. Usually people don't follow CERT warnings and all CVEs, so bundled libraries usually lead to security issues. That's often ignored for desktops at home, but in a larger environment (or even enterprise), that's a serious problem.
  • Having only one version of a library / external dependency instead of, say, 3, reduces the library-related memory footprint by 3 (shared libraries only loaded once!) and the space usage on disk by 3 (most filesystems don't deduplicate - and in any case the files will not all be exactly the same).
  • Distros usually test the library packaged against the other packages and check things don't break when appyling security patches.
  • Good maintainers often check there are no included trojans / data leaks in applications they package.
  • For non-rolling release distros: If you build something on your system yourself, you are usually guaranteed that the ABI of all installed system libraries does not change until the next major release of the distro. So you don't need to re-link things all too often.

So (most) distros are about:

  • Safety (without loads of manual effort)
  • Comfort
  • Stability

That's of course very much against the workings of very active projects, and fails if some library does not give any basic ABI stability across versions.
But it's usually in the interest of non-developer users who can just "use" their system without taking manual action each second day.

@eli-schwartz
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, and some distros harass application developers into supporting newer ffmpeg versions.

That said, I don't really get it either. Users should always know the fundamentals of how their system works, in my opinion.

Knowing the fundamentals of how their system works, is completely orthogonal to the question of vendored dependencies. I have no idea where you think you are going with this pseudo-logic.

@Hrxn
Copy link
Contributor

@Hrxn Hrxn commented on 83d44ac Nov 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Knowing the fundamentals of how their system works, is completely orthogonal to the question of vendored dependencies. I have no idea where you think you are going with this pseudo-logic.

This was a reply to the question raised by @jerkstore369 .

Anyone can just download mpv or any app for that matter themselves. I don't get it.

See that? Legit point, in my humble opinion.

I don't think it is asking too much if you expect someone to being able to fetch a source, and then apply make make install etc. pp.

@haasn
Copy link
Member

@haasn haasn commented on 83d44ac Nov 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Linux, it's pretty hard to distribute binary builds. The basic difference between Windows and Linux is that Windows provides a very stable system API, that is sufficient for doing most things. But on Linux, there isn't a single vendor. The only system guaranteed API is the kernel interface and maybe the libc, which are very bare and not suited for anything that does graphics. You need to depend on a number of third party libraries and you need to be able to load userspace-based drivers installed on those systems, which have all kinds of messy further dependencies.

Actually, what happens in practice on windows is that everybody and their mother distributes all dependencies alongside their program, which is why Program Files/Foo is full of dlls. mpv is no exception. (Alternatively, they statically link it all instead of filling their application dirs with dlls. And sometimes, they just dump their dependencies to system32 - directx/.NET/msvcrt are designed to work this way - which is why they still need installers)

There's absolutely nothing stopping you from doing the same for Linux, which is what shitty enterprise software does (into /opt, typically). The only reason it's so much more widespread for windows than it is for linux is because microsoft can't figure out package management.

Also, formats like AppImage literally exist to demonstrate this point; with AppImage you can distribute very portable linux software that only depends on the kernel API.

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Nov 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except the opposite is clearly true, users and distros have lots of issues with your terrible ideas.

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Nov 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

libav is a political fork, there is a good reason their about page does not list one technical feature, their reason for existing is not the least bit technical and entirely about drama. The much can be said about your ffmpeg-mpv fork. Additionally the only one that treated others like trash in the ffmpeg mailing list is you. Its not my responsibility to fix your attitude, if you want to drive mpv into the ground that is entirely on you. I am here just to help you understand how much of a disservice you have done to everyone.

@Earnestly
Copy link

@Earnestly Earnestly commented on 83d44ac Nov 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion this issue really has little to do with the ease at which someone can just build mpv or some other project locally, nor does it really have anything to do with vendoring.

Personally, and I don't know if I speak for anyone else, I see this more as a concern for the health of both projects. As most of us probably benefit quite a lot from the efforts put into both projects, it is distressing to see either side treating each other so vindictively.
ffmpeg has a responsibility to its users (such as mpv), to properly reflect real world requirements and to not simply shove the workload onto others if they get a design wrong. Likewise it has to be tempered with the understanding that not every feature a user wants can be realistically implemented.

@orbea To be fair, in that mailing list it's only Michael Niedermayer who seems to be technically out of date while using their position as vindication. Everyone else was welcoming, civil and even supportive of the patch while at the same time willing to put in the extra, unnecessary work Michael Niedermayer was stonewalling on. I see @wm4's reaction as a genuine response to, technically, bullshit.

@orbea
Copy link
Contributor

@orbea orbea commented on 83d44ac Nov 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Earnestly. It was not a genuine response, it was a tantrum to a reasonable request made by a ffmpeg dev. As @jerkstore369 points out, the important thing is that it works and right now its not out of pointless self sabotage.

Checking for Libav/FFmpeg library versions                           : no ('libavutil >= 56.0.100 libavcodec >= 58.2.100 libavformat >= 58.0.102 libswscale >= 5.0.101 libavfilter >= 7.0.101 libswresample >= 3.0.100' not found) 
Unable to find development files for some of the required FFmpeg/Libav libraries. You need git master. For FFmpeg, the mpv fork, that might contain additional fixes and features is required. It is available on https://github.com/mpv-player/ffmpeg-mpv Aborting.

Please sign in to comment.