[x265] Proposed solution to mixed 8/10 bit libraries

[Derek Buitenhuis]

On 3/31/2015 8:33 PM, Steve Borho wrote:

> /* fill in provided x265_api structure with methods suited for
>  * the provided encoder parameters. If 'p' is NULL you will get
>  * the system default libx265 library methods */
> void x265_get_api(x265_api* api, x265_param* p);

Relevant chat from IRC:

[21:29] < Daemon404> i think the general approach seems sane
[21:29] < Daemon404> i assume the API pointer returned would be static
[21:29] < Daemon404> i.e. not alloc'd
[21:31] < muggs> user allocated, you're passing in a struct you alloc
[21:31] < muggs> I'm not sure if that's important
[21:32] < Daemon404> hmm
[21:32] < muggs> it could be static, save a bit of work
[21:33] < Daemon404> https://github.com/vapoursynth/vapoursynth/blob/master/src/core/vsapi.cpp#L636
[21:33] < Daemon404> i was thinking like that
[21:33] < Daemon404> (struct is above it)
[21:33] < Daemon404> and below
[21:36] < muggs> yeah, something similar could work
[21:37] < muggs> the build number could be an argument
[21:37] < Daemon404> its a matter of opinion/taste i suppose
[21:38] < muggs> a little bike-shedding doesn't hurt


> This could be used for more than just selecting between Main and Main10
> builds, it could also select between PGO builds targeted for different
> use cases (file transcode vs real-time, etc).

I find it hard to believe this could provide a tangible speed benefit. Wouldn't
it be saner to profile everything for one build?

> The user applications don't have to be aware of the multi-lib details,
> and they should be able to use 8bpp and 16bpp encoders simultaneously
> within the same process, if they need to.

+1

- Derek