vcpkg
vcpkg copied to clipboard
microsoft
[ffmpeg] Update to 5.0
@Sibras ,Thanks for your pr, looks CI tested failed in many triplet, Please take a look: https://dev.azure.com/vcpkg/public/_build/results?buildId=68078&view=artifacts&pathAsName=false&type=publishedArtifacts
The errors in the CI were unfortunately somewhat expected. ffmpeg builds fine but several other packages fail due to ffmpeg 5.0 removing older deprecated API. So any project that hasnt updated accordingly now fails to compile.
From the CI the current packages that only work with ffmpeg 4.x and not 5.x are: aubio avcpp ignition opencv4 pangolin
These projects would need to be fixed or possibly do one of those unwanted but perhaps necessary dual ffmpeg ports.
add also opencv2 and opencv3 that are not tested by CI (which for compatibility reasons tests only opencv4) but are still used anyway
@Sibras ,Is this pr temporarily blocked?
Yep, I put it up so that people who want ffmpeg 5.0 know how to do it. But until a solution is provided to fix the downstream projects that are not compatible with 5.0 this PR is blocked.
Not sure what the best solution is to proceed. Either create a separate ffmpeg5 port, wait for some of those dependent projects to be fixed (some havnt been maintained for years so this is unlikely, opencv2/3 also unlikely to get fixed). Or have some way for dependency ports to specify what port versions (min/max) they support.
@Sibras ,Is this pr temporarily blocked?
Yep, I put it up so that people who want ffmpeg 5.0 know how to do it. But until a solution is provided to fix the downstream projects that are not compatible with 5.0 this PR is blocked.
Not sure what the best solution is to proceed. Either create a separate ffmpeg5 port, wait for some of those dependent projects to be fixed (some havnt been maintained for years so this is unlikely, opencv2/3 also unlikely to get fixed). Or have some way for dependency ports to specify what port versions (min/max) they support.
It seems like creating a new package (e.g., ffmpeg5) would be consistent with historical vcpkg practices, such as with opencv, sdl, etc.
For Gazebo and ignition we have patches upstream:
- https://github.com/osrf/gazebo/pull/3195
- https://github.com/ignitionrobotics/ign-common/pull/325
5.1 has been released: http://www.ffmpeg.org/download.html#release_5.1
5.1 has been released: http://www.ffmpeg.org/download.html#release_5.1
We still need some resolution on the API breakage of downstream ports. Once that has been resolved ill update this to 5.1.
@Sibras I am a third party, but personally I would prefer if vcpkg had 5.0 version committed before an update to 5.1 happens. It makes keeping versions in sync between different package management methods easier, and presumably update from 5.0(.1) to 5.1 should be relatively small diff due to being the same major version.
Ive resolved the current merge conflicts but at present this PR is still waiting for the blocking ports to be updated to support ffmpeg5. So still in the same position as when I first put this up.
How can this be a duplicate of a PR bumping ffmpeg to 4.4.3 instead of 5.0.0?
How can this be a duplicate of a PR bumping ffmpeg to 4.4.3 instead of 5.0.0?
@julianxhokaxhiu, Sorry for my misoperation, the versions released by ffmpeg are released alternately, the 4.4.3 version was released later than 5.0.0, so I made a mistake, I have reopened the PR
Thanks, no worries! All it counts is that we get this port working so we can merge ASAP. I'm waiting for it since a while as it's a dependency for one of my own projects. Looking forward!
Just to make sure: the update is (or at least seems to be) fine, but ffmpeg's dependees cannot use newer version yet?
@JonLiu1993 FFmpeg 5 has been the stable release for almost a year now, and not much progress has been made in recent months to upgrade the dependent ports. I propose forking the current ffmpeg port as ffmpeg4.4 or similar for incompatible ports, and upgrading the base ffmpeg port to version 5.
I understand having multiple ports is an increased maintenance burden, but Homebrew and virtually every Linux distro has already done this to deal with the incompatibilities. It's not realistic to expect every single port that depends on FFmpeg to be compatible with version 5.
I agree, especially I'm not sure where the vcpkg direction is going but to me it feels extremely slow. I wanted to open a discussion on this repo about this topic overall, since I have also a PR opened that is taking months to be merged. If this is a community lead project, probably we need to lower down the requirements barrier and start to accept contributions as they come if there's no one in MS capable or willing to work cooperatively in a manner of getting things done. I see more PRs getting stale than merged, and if we expect vcpkg to become a de-facto tool on the C++ world, we have to do much more than this IMHO.
Regarding this PR, let's find a middle term please because we can't keep it stale forever.
So all downstream projects need to be fixed for ffmpeg 5.0 unless that has been done this PR cannot be merged. This has also been the case for eigen3, openssl, etc.
Currently there is also a competing PR #28387
Regarding this PR, let's find a middle term please because we can't keep it stale forever.
If you need ffmpeg 5.0 in the meantime you can just an overlay.
Have you encounter the issue that building on triplet x64-windows will stuck at linking libavcodec? How do you resolve it?
If you need ffmpeg 5.0 in the meantime you can just an overlay.
All my projects are having an overlay but is this the way to go? What's the point of using vcpkg then? The idea here is to provide less work on my shoulders and use vcpkg as any other package manager for any other language ecosystem.
All my projects are having an overlay but is this the way to go?
Yes if it is not appropriate for the main repo (yet) an overlay is a valid solution.
What's the point of using vcpkg then?
ffmpeg has dependencies doesn't it? Do you have all of them overlayed? Also there is downstream use of ffmpeg which you probably also didn't overlay.
The idea here is to provide less work on my shoulders and use vcpkg as any other package manager for any other language ecosystem.
By having this PR open you are already reducing the workload of others since they can use this PR as a basis for their own overlays. Also at some point this or another PR updating ffmpeg will probably be merged. You are just not happy with the timescale but you could actively fix that by fixing all downstream usages and make CI happy ;).