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

[Deepthi Nandakumar]

Hello Derek,

We've enhanced x265 with the x265_api functionality to allow applications
to choose between 8bpp and 16bpp encoders at runtime. Is this something
ffmpeg would like to adopt?


On Wed, Apr 1, 2015 at 2:33 AM, Derek Buitenhuis <derek.buitenhuis at gmail.com
> 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?
>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20150429/b09721e3/attachment.html>