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

[Jason Garrett-Glaser]

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.

Jason