Bug#667573: x264: 10 bit builds

Jonathan Rosser jonathan.rosser at rd.bbc.co.uk
Thu Oct 11 21:16:13 UTC 2012


On 11/10/12 21:07, Jason Garrett-Glaser wrote:

>
> 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.

Indeed - that would be a mammoth task.

>> 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'm doing a dlopen() trick now and it works very well for my case.

The reason I replied to the original Debian bug report is that I
consider what I've done to be a bit of an ugly hack. (My packages
install a parallel version of x264 into /usr/x264-10bit/).

It would be good to come up with a way of installing the 8 and 10 bit
versions properly alongside each other.

I had considered modifying the configure script to allow the name
of the built libraries to be changed via a configure flag. I'd have
provided an alternative name for the 10 bit build.

Anyway - It is interesting to consider what the right thing to do
is, and how applications that want to do 8 or 10 bit interchangeably
should be constructed.

Regards,
Jonathan.



More information about the pkg-multimedia-maintainers mailing list