Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really?
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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
83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
π€£
True, true
83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
83d44ac
There was a problem hiding this comment.
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...
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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?
83d44ac
There was a problem hiding this comment.
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)
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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
83d44ac
There was a problem hiding this comment.
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?
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, lets take note that it seems that ffmpeg even fixed the issue!
https://trac.ffmpeg.org/ticket/6767#comment:5
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=a606f27f4c610708fa96e35eed7b7537d3d8f712
83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
It is the rule, not the exception...
83d44ac
There was a problem hiding this comment.
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.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, but release versions from when? This century?
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
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. π’
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. π
83d44ac
There was a problem hiding this comment.
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.
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.
83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
83d44ac
There was a problem hiding this comment.
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?
83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I just noticed it here too: https://abi-laboratory.pro/tracker/objects_report/ffmpeg/3.4/current/report.html
83d44ac
There was a problem hiding this comment.
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...)
83d44ac
There was a problem hiding this comment.
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...
ffmpeg-3.4-x86_64-1_SBo
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which one, if I may inquire?
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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:
So (most) distros are about:
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.
83d44ac
There was a problem hiding this comment.
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.
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.
83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a reply to the question raised by @jerkstore369 .
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.83d44ac
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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.
83d44ac
There was a problem hiding this comment.
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.