the 10bit useflag should create a new library since enabling it will change quite drastically libx264 behavior and e.g. make it refuse to encode baseline profile. vlc configure.ac has e.g.: PKG_CHECK_MODULES(X26410B, x26410b, [ so building a libx26410b with use=10bit could create this additional library and leave libx264 intact. see fftw-3 and multibuild.eclass for examples.
This is one of reasons why i added USE system-libx264 to media-video/x264-encoder. Nothing will use libx26410b, installing it is pointless. If you want stable system and also want 10bit encoding, you just install media-libs/x264[-10bit] and media-video/x264-encoder[10bit,-system-libx264].
(In reply to Nikoli from comment #1) > This is one of reasons why i added USE system-libx264 to > media-video/x264-encoder. Nothing will use libx26410b, installing it is > pointless. as above, maybe vlc? > If you want stable system and also want 10bit encoding, you just install > media-libs/x264[-10bit] and media-video/x264-encoder[10bit,-system-libx264]. its not about stable system but i see the 10bit useflag as an 'anti-feature' as such: it will be slower and reject most of encoding paramaters that used to work nicely. as for x264-encoder, it could also very well benefit from a double build: x264 and x26410b
> as above, maybe vlc? what do you mean? Until x264 upstream tells "libx26410b is correct and _only_ correct name 10 bit libx264" nothing should use. Adding some hacks to various build systems is not nice. > its not about stable system but i see the 10bit useflag as an 'anti-feature' as such: it will be slower and reject most of encoding paramaters that used to work nicely. But if someone wants to use /usr/bin/ffmpeg or mpv for 10bit encoding, he needs 10bit libx264. And it is possible, that nothing else in his system is using libx264. >as for x264-encoder, it could also very well benefit from a double build: x264 and x26410b When and which of 2 x264cli bins should use internal or shared libx264 in such scenario?
(In reply to Nikoli from comment #3) > > as above, maybe vlc? > what do you mean? Until x264 upstream tells "libx26410b is correct and > _only_ correct name 10 bit libx264" nothing should use. Adding some hacks to > various build systems is not nice. I'm not saying the situation is perfect, but vlc could provide a x264 10bits encoder with libx26410b.{so,pc} it seems while keeping the 8bits encoder with libx264.{so,pc}. > > its not about stable system but i see the 10bit useflag as an 'anti-feature' as such: it will be slower and reject most of encoding paramaters that used to work nicely. > > But if someone wants to use /usr/bin/ffmpeg or mpv for 10bit encoding, he > needs 10bit libx264. And it is possible, that nothing else in his system is > using libx264. That's true. I don't know mpv but ffmpeg/avconv/libavcodec will configure its x264 encoder depending on _runtime_ settings of x264_bit_depth. This means that we could switch libx264.so.$VERSION dynamically between the 8 and 10 bits depth. At the moment it just sucks to have to recompile x264 to produce "portable 8 bits" videos or "high quality 10bits" videos... How do binary distros handle this? Are less bleeding edge packages from http://qa-reports.gentoo.org/output/genrdeps/rindex/media-libs/x264 fine with x264 built with 10bits depth? > >as for x264-encoder, it could also very well benefit from a double build: x264 and x26410b > > When and which of 2 x264cli bins should use internal or shared libx264 in > such scenario? both can use (different) shared libs
Hacking the build system to change the output soname seems like a fairly large drift from upstream. The only way to do this sanely is to have the 10bit USE flag trigger a double-compile, and install the regular library at libx264.*.so and the 10bit at libx26410b.*.so. Just flat out changing the output soname based on a USE flag is a bad idea.
(In reply to Patrick McLean from comment #5) see comment #0
Ok, I might look at this if I have time. Since this is more of a feature request/enhancement than a regression from the bump I made yesterday, I am reassigning it to the herd.
Is this still a thing?
this can be closed since the lib can do both 8 & 10 bits now
