y4m [info]: 384x288p 0:0 @ 25/1 fps (cfr) depth [error]: this build supports only bit depth 8 y4m [info]: 384x288p 0:0 @ 25/1 fps (cfr) depth [error]: this build supports only bit depth 8 Makefile:233: recipe for target 'fprofiled' failed gmake[2]: *** [fprofiled] Error 255 gmake[2]: Leaving directory '/usr/ports/multimedia/x264/work/x264-snapshot-20140827-2245-stable' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make[1]: stopped in /usr/ports/multimedia/x264 *** Error code 1 Stop. make: stopped in /usr/ports/multimedia/x264
Auto-assigned to maintainer koobs@FreeBSD.org
Did you specify the 10-bit option for libx264? Can you build other ports that use libx264 such as ffmpeg?
(In reply to Andrew Berg from comment #2) > Did you specify the 10-bit option for libx264? Can you build other ports > that use libx264 such as ffmpeg? So it turns out that 10-bit option doesn't work yet?
(In reply to mikhail.rokhin from comment #3) > (In reply to Andrew Berg from comment #2) > > Did you specify the 10-bit option for libx264? Can you build other ports > > that use libx264 such as ffmpeg? > > So it turns out that 10-bit option doesn't work yet? It's supposed to work, but it is a different issue if you are getting a message like that and you are using 8-bit. I haven't been able to reproduce the issue or test some things since profiling requires GCC and I'm having problems getting that to build in my Poudriere instance at the moment.
I can reproduce the issue. The problem seems to be that profiling cares about bit depth and there isn't a way to automatically specify the correct bit depth (so the default of 8 is used) during the x264 build. As a workaround for the time being, you can disable profiling when building x264. My quick tests show that applications using the library (including x264 itself) will have no issues with a 10-bit libx264.
It turns out that I ended up breaking 10-bit for x264 completely, and profiling just makes it complain sooner. The x264 configure script must explicitly be told to use 10-bit, even though it figures out that libx264 is 10-bit. Hopefully, this can be resolved by having upstream change the configure script. I did an actual encode with ffmpeg using 10-bit libx264 and it does result in a playable 10-bit video, so I think this is confined to the x264 application itself.
Created attachment 150907 [details] Patch to remove build specific x264_config.h This may require a bit more work, but it should be possible to get it to use the installed version of the header, instead of the one ./configure generates.
Created attachment 150911 [details] Remove x264_config.h from WRKSRC, as we use the system's libx264 include instead.
A commit references this bug: Author: koobs Date: Sat Dec 27 10:17:55 UTC 2014 New revision: 375676 URL: https://svnweb.freebsd.org/changeset/ports/375676 Log: multimedia/x264: Use libx264's config headers An encoding error condition is created when HI10P is enabled in libx264, since the x264 is not built with that options. Make x264 use the headers provided by the libx264 port, not the ones that come with the sources, so the configuration options between the two ports (libx264 and x264) can't end up mismatched. Thanks to astrodog and a_b (IRC) for coming up with an elegant solution. [1] While I'm here: - Update COMMENT to reflect this is just the x264 CLI frontend - Add LICENSE_FILE - Tweak BUILD_DEPENDS - Sort USES and OPTIONS - Update GCC_DESC to match libx264 - Use OPTIONS helpers (except for PGO & GCC .. *shakes fist*) - Sort PLIST_* - Remove conditional LDFLAGS (-fstack-protector is now handled by the framework) - Whitespace alignment - Remove pkgconfig REINPLACE_CMD, its not needed here. - Strip x264 binary x264 PR: 195292 [1] Submitted by: Harrison Grundy <harrison dot grundy at astrodoggroup com> Changes: head/multimedia/x264/Makefile
Committed, Thanks Mikhail, Andrew, & Harrison!