On Sun, Oct 25, 2015 at 4:56 AM, Ronald S. Bultje
wrote:
>
> So this is likely because we init all tables instead of just these that we
> need, right? So how about having one ff_once per table? That should be
> trivial to implement.
Just so we're all on the same page, this is trivial, but will g
On Wed, 28 Oct 2015 01:06:38 +0100
Michael Niedermayer wrote:
> On Tue, Oct 27, 2015 at 10:14:49AM +0100, wm4 wrote:
> > On Mon, 26 Oct 2015 13:15:39 -0700
> > Dale Curtis wrote:
> >
> > > On Sun, Oct 25, 2015 at 4:56 AM, Ronald S. Bultje
> > > wrote:
> > > >
> > > > So this is likely beca
On Tue, Oct 27, 2015 at 10:14:49AM +0100, wm4 wrote:
> On Mon, 26 Oct 2015 13:15:39 -0700
> Dale Curtis wrote:
>
> > On Sun, Oct 25, 2015 at 4:56 AM, Ronald S. Bultje
> > wrote:
> > >
> > > So this is likely because we init all tables instead of just these that we
> > > need, right? So how about
On Mon, 26 Oct 2015 13:15:39 -0700
Dale Curtis wrote:
> On Sun, Oct 25, 2015 at 4:56 AM, Ronald S. Bultje
> wrote:
> >
> > So this is likely because we init all tables instead of just these that we
> > need, right? So how about having one ff_once per table? That should be
> > trivial to implemen
On Sun, Oct 25, 2015 at 4:56 AM, Ronald S. Bultje
wrote:
>
> So this is likely because we init all tables instead of just these that we
> need, right? So how about having one ff_once per table? That should be
> trivial to implement.
>
(from the right account this time)
Just so we're all on the s
Hi,
On Sun, Oct 25, 2015 at 9:39 AM, wm4 wrote:
> On Sun, 25 Oct 2015 07:56:49 -0400
> "Ronald S. Bultje" wrote:
>
> > Hi,
> >
> > On Sun, Oct 25, 2015 at 7:48 AM, Derek Buitenhuis <
> > derek.buitenh...@gmail.com> wrote:
> >
> > > On 10/25/2015 11:44 AM, Michael Niedermayer wrote:
> > > >> One
On Sun, 25 Oct 2015 07:56:49 -0400
"Ronald S. Bultje" wrote:
> Hi,
>
> On Sun, Oct 25, 2015 at 7:48 AM, Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
>
> > On 10/25/2015 11:44 AM, Michael Niedermayer wrote:
> > >> One could argue this is not a representative sample. It's a single
On 10/25/2015 11:56 AM, Michael Niedermayer wrote:
> the problem that causes the slowdown should be due to initializing all
> table sizes when only 1 or a few small ones are needed
> making the init more fine grained (as it was) should solve this
> that could be done with a single mutex (not of onc
On 10/25/2015 11:56 AM, Ronald S. Bultje wrote:
> So this is likely because we init all tables instead of just these that we
> need, right? So how about having one ff_once per table? That should be
> trivial to implement.
Yep.
> Obviously anyone using shell scripts and calls to CLI ffmpeg version
On Sun, Oct 25, 2015 at 11:48:12AM +, Derek Buitenhuis wrote:
> On 10/25/2015 11:44 AM, Michael Niedermayer wrote:
> >> One could argue this is not a representative sample. It's a single small
> >> file,
> >> which must always init (as opposed to a longer running process such as
> >> Chrome.
Hi,
On Sun, Oct 25, 2015 at 7:48 AM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:
> On 10/25/2015 11:44 AM, Michael Niedermayer wrote:
> >> One could argue this is not a representative sample. It's a single
> small file,
> >> which must always init (as opposed to a longer running process
On 10/25/2015 11:44 AM, Michael Niedermayer wrote:
>> One could argue this is not a representative sample. It's a single small
>> file,
>> which must always init (as opposed to a longer running process such as
>> Chrome.
>> Whereas if you have a longer sample, it wouldn't even be within the margi
On Sun, Oct 25, 2015 at 11:19:53AM +, Derek Buitenhuis wrote:
> On 10/25/2015 11:09 AM, Michael Niedermayer wrote:
> > on ARM (cubox) this changes
> > time ./ffmpeg -i ~/fate-suite/qt-surge-suite/surge-2-16-B-QDM2.mov
> > from
> > real0m0.028s
> > user0m0.010s
> > sys 0m0.010s
> >
On 10/25/2015 11:09 AM, Michael Niedermayer wrote:
> on ARM (cubox) this changes
> time ./ffmpeg -i ~/fate-suite/qt-surge-suite/surge-2-16-B-QDM2.mov
> from
> real0m0.028s
> user0m0.010s
> sys 0m0.010s
>
> real0m0.028s
> user0m0.020s
> sys 0m0.000s
>
>
> to
>
> real0
On Fri, Oct 23, 2015 at 03:35:15PM -0700, Dale Curtis wrote:
> Changes from partial initialization which happens for every
> initialize call to a full initialization once per process. Changes
> as discussed on list by wm4 and rbultje.
>
> Passes fft-test and fate suite.
on ARM (cubox) this change
On Fri, 23 Oct 2015 15:35:15 -0700
Dale Curtis wrote:
> Changes from partial initialization which happens for every
> initialize call to a full initialization once per process. Changes
> as discussed on list by wm4 and rbultje.
>
> Passes fft-test and fate suite.
>
> Signed-off-by: Dale Curtis
Changes from partial initialization which happens for every
initialize call to a full initialization once per process. Changes
as discussed on list by wm4 and rbultje.
Passes fft-test and fate suite.
Signed-off-by: Dale Curtis
---
libavcodec/fft_template.c | 33 -
17 matches
Mail list logo
