<div dir="ltr"><div><div><div>Hello Derek,<br><br></div>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?<br></div></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 1, 2015 at 2:33 AM, Derek Buitenhuis <span dir="ltr"><<a href="mailto:derek.buitenhuis@gmail.com" target="_blank">derek.buitenhuis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 3/31/2015 8:33 PM, Steve Borho wrote:<br>
<br>
> /* fill in provided x265_api structure with methods suited for<br>
>  * the provided encoder parameters. If 'p' is NULL you will get<br>
>  * the system default libx265 library methods */<br>
> void x265_get_api(x265_api* api, x265_param* p);<br>
<br>
</span>Relevant chat from IRC:<br>
<br>
[21:29] < Daemon404> i think the general approach seems sane<br>
[21:29] < Daemon404> i assume the API pointer returned would be static<br>
[21:29] < Daemon404> i.e. not alloc'd<br>
[21:31] < muggs> user allocated, you're passing in a struct you alloc<br>
[21:31] < muggs> I'm not sure if that's important<br>
[21:32] < Daemon404> hmm<br>
[21:32] < muggs> it could be static, save a bit of work<br>
[21:33] < Daemon404> <a href="https://github.com/vapoursynth/vapoursynth/blob/master/src/core/vsapi.cpp#L636" target="_blank">https://github.com/vapoursynth/vapoursynth/blob/master/src/core/vsapi.cpp#L636</a><br>
[21:33] < Daemon404> i was thinking like that<br>
[21:33] < Daemon404> (struct is above it)<br>
[21:33] < Daemon404> and below<br>
[21:36] < muggs> yeah, something similar could work<br>
[21:37] < muggs> the build number could be an argument<br>
[21:37] < Daemon404> its a matter of opinion/taste i suppose<br>
[21:38] < muggs> a little bike-shedding doesn't hurt<br>
<span class=""><br>
<br>
> This could be used for more than just selecting between Main and Main10<br>
> builds, it could also select between PGO builds targeted for different<br>
> use cases (file transcode vs real-time, etc).<br>
<br>
</span>I find it hard to believe this could provide a tangible speed benefit. Wouldn't<br>
it be saner to profile everything for one build?<br>
<span class=""><br>
> The user applications don't have to be aware of the multi-lib details,<br>
> and they should be able to use 8bpp and 16bpp encoders simultaneously<br>
> within the same process, if they need to.<br>
<br>
</span>+1<br>
<span class="HOEnZb"><font color="#888888"><br>
- Derek<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" target="_blank">https://mailman.videolan.org/listinfo/x265-devel</a><br>
</div></div></blockquote></div><br></div>