This upgrades the port from 3.5 to 4.0. The changes are listed under the URL. Some new options are now available, but disabled by default -- as they are in the upstream code. In addition to committing the port, depending ports will need to have their PORTREVISION bumped -- portmgr@ has been planning to automate this part since, at least, 2007, but has more important things to do. This patch does not include such changes to other ports, as those are all moving targets.
Maintainer informed via mail
Looks like the actual patch is missing.
You forgot to attach the patch.
Created attachment 253836 [details] Upgrade x265 to 4.0 > Looks like the actual patch is missing. > You forgot to attach the patch. Argh... Thank you, gentlemen, for your patience...
I strongly recommend you change your Bugzilla email address to be the same as your maintainer email address or vice versa, this makes it easier to see that you are the maintainer. As option ASM collides with DEBUG, consider using OPTIONS_RADIO for these two. The following patches no longer apply: - files/patch-source_common_ppc_intrapred__altivec.cpp - files/patch-source_x265.h Please check and resubmit.
Created attachment 253863 [details] New version with obsolete patches actually removed > As option ASM collides with DEBUG, consider using OPTIONS_RADIO for these two. Sorry, I don't understand, where you see this conflict... > The following patches no longer apply: > - files/patch-source_common_ppc_intrapred__altivec.cpp > - files/patch-source_x265.h Oh, I did have them `git rm`-ed here, but `git diff` ignored that... Thanks!
(In reply to Mikhail T. from comment #6) See these two lines: DEBUG_PREVENTS= OPTIMIZED_FLAGS DEBUG_PREVENTS_MSG= Optimizations are incompatible with debugging code Your new patch looks better. For the future, ideally submit patches as produced by "git format-patch", not "git diff" as these are easier to deal with. Is there a particular reason the ASM option isn't enabled by default?
What email address would you prefer for the commit? I can use both the ports@ one and the freebsd-2024@ one.
Oh, plz, without: .for o in ALPHA MULTIVIEW SCC_EXT SVTHEVC VMAF $o_CMAKE_BOOL= ENABLE_${o:S/SVTHEVC/SVT_HEVC/} # Our legacy name does not match vendor's .endfor
(In reply to Robert Clausecker from comment #7) > DEBUG_PREVENTS= OPTIMIZED_FLAGS Oh, that -- you said "ASM conflicts with DEBUG" earlier. That line is there since 2021 -- by joneium@. It has nothing to do with the upgrade and may not even be necessary any more, let me test. > Is there a particular reason the ASM option isn't enabled by default? It is enabled by default for some platforms -- but not others. Maybe, it should be enabled for more -- perhaps, even all -- but, since I cannot test it, I was being cautious. We can try... > "git format-patch", not "git diff" Don't you need to commit (even if locally) for format-patch to work? Since I can no longer push anything, I avoid committing for fear of messing up a future pull. The `git diff HEAD -- .` is how I obtained the current patch. (In reply to Vladimir Druzenko from comment #9) > Oh, plz, without: > .for o in ALPHA MULTIVIEW SCC_EXT SVTHEVC VMAF The method is neither explicitly prohibited by any document, nor even unprecedented -- take a look at the /usr/share/mk/gendirdeps.mk for example. You don't have to use such single-letter variable-names yourself, but it shouldn't be a show-stopper, if others do...
Created attachment 253871 [details] Upgrade x265 to 4.0, version 3 1. Turn ASM on by default for all platforms. 2. Turn optimization into a radio-button: OPTIMIZED_FLAGS vs. DEBUG. If neither are selected, the C/CXXFLAGS remain unmodified. (In reply to Robert Clausecker from comment #8) > What email address would you prefer for the commit? Let's stick with the current one -- for consistency with all of my other ports.
emulators/fceux fails to build with attachment #253863 [details]: /wrkdirs/usr/ports/emulators/fceux/work/fceux-2.6.6/src/drivers/Qt/AviRecord.cpp:463:8: error: no matching function for call to 'x265_encoder_encode' ret = x265_encoder_encode( hdl, &nal, &i_nal, pic, &pic_out ); ^~~~~~~~~~~~~~~~~~~ /usr/local/include/x265.h:2496:5: note: candidate function not viable: no known conversion from 'x265_picture *' to 'x265_picture **' for 5th argument int x265_encoder_encode(x265_encoder *encoder, x265_nal **pp_nal, uint32_t *pi_nal, x265_picture *pic_in, x265_picture **pic_out); ^ /wrkdirs/usr/ports/emulators/fceux/work/fceux-2.6.6/src/drivers/Qt/AviRecord.cpp:496:12: error: no matching function for call to 'x265_encoder_encode' ret = x265_encoder_encode( hdl, &nal, &i_nal, NULL, &pic_out ); ^~~~~~~~~~~~~~~~~~~ /usr/local/include/x265.h:2496:5: note: candidate function not viable: no known conversion from 'x265_picture *' to 'x265_picture **' for 5th argument int x265_encoder_encode(x265_encoder *encoder, x265_nal **pp_nal, uint32_t *pi_nal, x265_picture *pic_in, x265_picture **pic_out); ^ 2 errors generated. If this is a known API change, I can try to engineer a patch to work around this issue. If not, please investigate and fix your patch if possible. It may be necessary to keep the old version in something like multimedia/x265v3 if API differences prove to be insurmountable. I'll try attachment #253871 [details] once this run is complete (tomorrow-ish).
Apparently libheif is affected too, and not in a good way: https://mailman.videolan.org/pipermail/x265-devel/2024-September/013945.html And so is vlc: https://code.videolan.org/videolan/vlc/-/issues/28799 This is a blocker. How would you like to proceed?
(In reply to Robert Clausecker from comment #12) > error: no matching function for call to 'x265_encoder_encode' Looks like the method was changed by this commit in August: https://bitbucket.org/multicoreware/x265_git/commits/c69c113960834400545bc4bce2830ff51dcb86b3 So, it, probably, is permanent... > How would you like to proceed? We can try updating the port to 3.6 instead of 4.0 -- and wait for the depending ports to catch up to the API change... (Or, maybe, x265 maintainers will come to their senses and, at least, introduce a compatibility shim, but that's unlikely.)
(In reply to Mikhail T. from comment #11) Yeah, you need to do a local commit for git-format-patch to work. The idea is that the commit has your commit message and authorship information, so I don't have to come up with something that may not represent your intent. git pull should still work (I recommend setting it to rebase your changes), or you could make the commit on some other branch.
(In reply to Mikhail T. from comment #14) Updating to v3.6 is fine with me. I can offer you to commit your update to v4.0 to a separate port multimedia/x265v4 or something like that so consumers who do require the new API can get it. Or we put v3.6 into multimedia/x265v3 and the 4.0 update into multimedia/x265v4 or something to that effect. The v4.0 release is very new, so maybe they'll revisit their choice of changing the API in such a dangerous way. You decide.
(In reply to Mikhail T. from comment #10) > The method is neither explicitly prohibited by any document, nor even unprecedented -- > take a look at the /usr/share/mk/gendirdeps.mk for example. You don't have to use such > single-letter variable-names yourself, but it shouldn't be a show-stopper, if others do... It's not about "single-letter variable-names", it's about the entire loop. It makes the code worse - harder to read and harder to understand. And it doesn't make the code smaller - 3 lines with a substitution instead of 5 very-very simple definitions. Production code is not the place for this kind of code, IMHO.
While I respect vvd@'s opinion on this matter, I'll leave it up to the maintainer to decide how to handle OPT_CMAKE_BOOL. I'm fine with either approach.
Created attachment 253880 [details] Upgrade to 3.6 instead of 4.0 vvd@ "wins" for now, because there are only two options to turn on 3.6 :-) The libvmaf-support remains broken, because our port of the dependency has been upgraded to 3.0.0, which is only supported by x265-4.0 Not removing this option for the sake of those, who might have kept the older vmaf on their systems. I don't think, setting up the x265v4 is worth it at this time -- the new release is too fresh. Let's wait for the incompatibilities to be resolved one way or the other...
Created attachment 253892 [details] armv FreeBSD 14 build log (failing) Build fails on armv7 FreeBSD 14, see attached log file.
Any chance you can let me into that ARMv7 box remotely?
(In reply to Mikhail T. from comment #21) Sure, please send me an email with an SSH key and a desired user name and I can let you it.
Sent you an email. Check your spam folder if you didn't get it.
Created attachment 253926 [details] Upgrade to 3.6 with fixes for ARM and removing the ASM-option > Build fails on armv7 FreeBSD 14 The latest edition provides fixes for the 32-bit ARM, and drops the need for gcc/binutils on the 64-bit ARM (aarch64). Many thanks to fuz@ for providing remote access to the two ARM-systems. The ASM is no longer an option -- it was always a requirement on some platforms, and is very useful on others. PowerPC architecture(s) remain untested, unfortunately...
Created attachment 253927 [details] Upgrade to 3.6 with fixes for ARM and removing the ASM-option Duh, actually include the patch for ARM assembly code...
(In reply to Mikhail T. from comment #25) Thank you for the update. Unfortunately acceptance testing for these patches will take a while as I am just updating my test build jail to 14.1 (14.0 is out of support now) and it'll take a while to rebuild all dependencies.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=90e15809d954e2ef0c018d4e1543c7fee56dfc64 commit 90e15809d954e2ef0c018d4e1543c7fee56dfc64 Author: Robert Clausecker <fuz@FreeBSD.org> AuthorDate: 2024-09-28 14:08:31 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2024-10-06 11:49:16 +0000 */*: bump port revisions of dependents following x265 updates PR: 281680 cad/opencascade/Makefile | 2 +- emulators/fceux/Makefile | 2 +- graphics/digikam/Makefile | 2 +- graphics/libbpg/Makefile | 2 +- graphics/libheif/Makefile | 1 + multimedia/avidemux/Makefile | 2 +- multimedia/emby-server/Makefile | 1 + multimedia/ffmpeg/Makefile | 2 +- multimedia/ffmpeg4/Makefile | 2 +- multimedia/gstreamer1-plugins-x265/Makefile | 2 +- multimedia/vlc/Makefile | 2 +- 11 files changed, 11 insertions(+), 9 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=7c8a3f43dc8455ad4c80782e172f8f0926b2cc99 commit 7c8a3f43dc8455ad4c80782e172f8f0926b2cc99 Author: Mikhail T. <freebsd-2024@virtual-estates.net> AuthorDate: 2024-10-01 14:45:56 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2024-10-06 11:49:16 +0000 multimedia/x265: update to 3.6 The latest edition provides fixes for the 32-bit ARM, and drops the need for gcc/binutils on the 64-bit ARM (aarch64). Many thanks to fuz@ for providing remote access to the two ARM-systems. The libvmaf-support remains broken, because our port of the dependency has been upgraded to 3.0.0, which is only supported by x265-4.0. Not removing this option for the sake of those, who might have kept the older vmaf on their systems. The ASM is no longer an option -- it was always a requirement on some platforms, and is very useful on others. PR: 281680 multimedia/x265/Makefile | 63 +++---- multimedia/x265/distinfo | 8 +- multimedia/x265/files/patch-arm-assembly (new) | 117 +++++++++++++ multimedia/x265/files/patch-source_CMakeLists.txt | 14 +- ...source_common_ppc_intrapred__altivec.cpp (gone) | 14 -- multimedia/x265/files/patch-source_encoder_api.cpp | 2 +- multimedia/x265/files/patch-source_x265.h (gone) | 13 -- multimedia/x265/files/patch-warnings | 193 ++++++++++++++++++--- multimedia/x265/pkg-plist | 2 +- 9 files changed, 320 insertions(+), 106 deletions(-)
Thank you for your contribution.