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

[Steve Borho]

On 03/31, Derek Buitenhuis wrote:
> 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?

I've never tried it, to be honest.

> > 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
> 
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel

-- 
Steve Borho