Here is the branch with pull request to facilitate review:
https://github.com/mltframework/mlt/pull/183
On Sun, Jan 29, 2017 at 1:24 PM Dan Dennedy wrote:
> I will combine ideas from the last two messages and put it into a branch
> for further review. I have not yet decided whether to include th
I will combine ideas from the last two messages and put it into a branch
for further review. I have not yet decided whether to include this main new
getter/creator function in mlt_slices or mlt_factory.
On Sun, Jan 29, 2017 at 1:47 AM Maksym Veremeyenko
wrote:
> On 29.01.2017 1:40, Brian Matherl
On 29.01.2017 1:40, Brian Matherly wrote:
> I've not used the slices module nor studied it deeply. So here are some
> random comments for your consideration.
>
> * Who would be responsible for *first* initializing the global pool?
>
> * Whoever calls it first "wins" by being able to decide the numb
ay, January 28, 2017 8:07 PM
Subject: Re: [Mlt-devel] RFC mlt_slices global shared pool
On Sat, Jan 28, 2017 at 3:40 PM Brian Matherly wrote:
I've not used the slices module nor studied it deeply. So here are some random
comments for your consideration.
* Who would be responsible for *
y random ideas.
>
> Cheers,
>
> ~Brian
>
> --
> *From:* Dan Dennedy
> *To:* Maksym Veremeyenko ; mlt-devel <
> mlt-devel@lists.sourceforge.net>
> *Sent:* Saturday, January 28, 2017 3:19 PM
> *Subject:* [Mlt-devel] RFC mlt_slices global sh
ect: [Mlt-devel] RFC mlt_slices global shared pool
It seems to me that outside of the special high-priority, low-latency producer
and consumers, most services should be using one global shared pool to prevent
too many pools and threads created. Here is a code change I am playing with t
It seems to me that outside of the special high-priority, low-latency
producer and consumers, most services should be using one global shared
pool to prevent too many pools and threads created. Here is a code change I
am playing with to add function mlt_slices_init_global_pool(int threads),
which r
