On Mon, Mar 14, 2016 at 2:13 PM, Claudio Freire wrote:
> On Sun, Mar 13, 2016 at 10:30 PM, Ganesh Ajjanagadde
> wrote:
>> /**
>> * Calculate rate distortion cost for quantizing with given codebook
>> @@ -105,7 +106,7 @@ static av_always_inline float
>> quantize_and_encode_band_cost_template(
On Sun, Mar 13, 2016 at 10:30 PM, Ganesh Ajjanagadde wrote:
> /**
> * Calculate rate distortion cost for quantizing with given codebook
> @@ -105,7 +106,7 @@ static av_always_inline float
> quantize_and_encode_band_cost_template(
> curbits += 21;
>
There is no reason for computing cbrtf at runtime; we have a table for
this.
Yields a negligible speedup.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/aacenc.c | 2 ++
libavcodec/aacenc_quantization.h | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavc
On Sat, Mar 12, 2016 at 12:09:13PM -0500, Ganesh Ajjanagadde wrote:
> And yes, for me the proof of the pudding is in the eating. In other
> words, if you or someone else sends a small, simple patch achieving
> the above one-line change, I will be very happy and will learn
> something.
I don't thin
On Sat, Mar 12, 2016 at 12:09:13PM -0500, Ganesh Ajjanagadde wrote:
> And yes, for me the proof of the pudding is in the eating. In other
> words, if you or someone else sends a small, simple patch achieving
> the above one-line change, I will be very happy and will learn
> something.
Does that me
On Sat, Mar 12, 2016 at 11:35 AM, Reimar Döffinger
wrote:
> On Sat, Mar 12, 2016 at 10:21:10AM -0500, Ganesh Ajjanagadde wrote:
>> Ok. Let me put it this way: I have a super simple patch that simply
>> moves stuff to cbrt_data.c and works perfectly well under default
>> configure, with no changes
On Sat, Mar 12, 2016 at 10:21:10AM -0500, Ganesh Ajjanagadde wrote:
> Ok. Let me put it this way: I have a super simple patch that simply
> moves stuff to cbrt_data.c and works perfectly well under default
> configure, with no changes to the Makefile apart from adding
> cbrt_data.o to the list of o
On Fri, Mar 11, 2016 at 3:05 AM, Reimar Döffinger
wrote:
> On 11.03.2016, at 03:48, Ganesh Ajjanagadde wrote:
>
>> On Thu, Mar 10, 2016 at 3:12 AM, Reimar Döffinger
>> wrote:
>>> On 10.03.2016, at 00:49, Ganesh Ajjanagadde wrote:
>>>
There is no reason for computing cbrtf at runtime; we ha
On 11.03.2016, at 03:48, Ganesh Ajjanagadde wrote:
> On Thu, Mar 10, 2016 at 3:12 AM, Reimar Döffinger
> wrote:
>> On 10.03.2016, at 00:49, Ganesh Ajjanagadde wrote:
>>
>>> There is no reason for computing cbrtf at runtime; we have a table for
>>> this.
>>>
>>> Cruft needed due to the build s
On Thu, Mar 10, 2016 at 3:12 AM, Reimar Döffinger
wrote:
> On 10.03.2016, at 00:49, Ganesh Ajjanagadde wrote:
>
>> There is no reason for computing cbrtf at runtime; we have a table for
>> this.
>>
>> Cruft needed due to the build system, the people who still like using
>> hardcoded tables and ne
On Thu, Mar 10, 2016 at 2:46 AM, Hendrik Leppkes wrote:
> On Thu, Mar 10, 2016 at 12:49 AM, Ganesh Ajjanagadde
> wrote:
>> There is no reason for computing cbrtf at runtime; we have a table for
>> this.
>>
>> Cruft needed due to the build system, the people who still like using
>> hardcoded tabl
On 10.03.2016, at 00:49, Ganesh Ajjanagadde wrote:
> There is no reason for computing cbrtf at runtime; we have a table for
> this.
>
> Cruft needed due to the build system, the people who still like using
> hardcoded tables and need for single cbrt_tab across the code.
Could you please explain
On Thu, Mar 10, 2016 at 12:49 AM, Ganesh Ajjanagadde wrote:
> There is no reason for computing cbrtf at runtime; we have a table for
> this.
>
> Cruft needed due to the build system, the people who still like using
> hardcoded tables and need for single cbrt_tab across the code.
>
The build-syste
There is no reason for computing cbrtf at runtime; we have a table for
this.
Cruft needed due to the build system, the people who still like using
hardcoded tables and need for single cbrt_tab across the code.
Yields non-negligible speedup (Haswell+GCC, -march=native)
before:
ffmpeg -i sin.flac -
14 matches
Mail list logo
