[x264-devel] Bug#667573: x264: 10 bit builds

[Pavel Koshevoy]

On 10/11/2012 2:07 PM, Jason Garrett-Glaser wrote:
> On Thu, Oct 11, 2012 at 9:46 AM, Reinhard Tartler <siretart at gmail.com> wrote:
>> tags 667573 upstream
>> forwarded 667573 x264-devel at videolan.org
>> severity 667573 wishlist
>> stop
>>
>> Dear x264 developers,
>>
>> The following quote is taken from a debian bug report that has been
>> filed against the debian x264 package. The full buglog can be read at
>> http://bugs.debian.org/667573
>>
>> On Thu, Oct 11, 2012 at 2:55 AM, Jonathan Rosser
>> <jonathan.rosser at rd.bbc.co.uk> wrote:
>>> It would be really good to get a proper solution to this. I currently
>>> require 8 bit and 10bit of x264 to be available to the same application
>>> at the same time.
>>>
>>> A typical use case would be simultaneously encoding 10bit 4:2:2 and 8
>>> bit 4:2:0 versions of the same source video, this cannot be achieved
>>> with linkage to a single x264 library.
>>>
>>> [Alternatively an application that can encode in either 8 or 10 bit
>>> modes is equally difficult to write]
>>>
>>> I have resorted to building my own custom .deb for the 10 bit version
>>> which installs to /usr/x264-10bit/... then a plug-in architecture and
>>> dlopen() allow one executable to dynamically link against both the 8 and
>>> 10bit versions and keep both sets of symbols isolated from each other.
>>>
>>> This is all fairly hohrrible, but works....
>>>
>>> I don't see the 8 or 10 bit versions as been "alternatives" (overloaded
>>> terminology, sorry!), I need them to be able to co-exist.
>>>
>>> Anyway, just some input to help define what might be useful for a 10bit
>>> x264 package.
>> Thanks for your bug report.
>>
>> Unfortunately, I don't see a good way how we can provide this
>> functionality cleanly in Debian without the help of upstream. I
>> understand that the 10bit implementation uses a lot of CPP magic to
>> reuse a lot of code, but to me the sanest solution to this problem
>> seems to me to compile twice. Is there any way to make the libx264.so
>> library provide both 8bit and 10bit encoding?
> It'd be very difficult to do this; we'd effectively have to version
> every single symbol so that they don't collide, then template all the
> appropriate code.  It'd be a lot of work and I don't know anyone
> willing to do it.
>
>> Jonathan, until tihs is resolved, I would suggest you to compiled x264
>> as  static library and link your applications against that build.
>> Inconvenient, but I don't see a better solution right now.
> Would dlopen() work to hack around this sort of limitation?  I recall
> seeing a hack for x264cli that allowed both 8-bit and 10-bit encoding
> by doing this.

I can confirm that I use both 10-bit and 8-bit builds of x264 share lib 
in one app (dynamically loaded on OSX and Win32), and select the 
appropriate instance based on the bit-depth of incoming source data.

     Pavel.