Use saturating addition functions instead of 64-bit intermediates
and separate clipping. This is much faster when dedicated
instructions are available.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Firstly, nothing in this function can overflow 32 bits so the use
of a 64-bit type is completely unnecessary. Secondly, the scale
is either a power of two or 0x7fff. Doing separate loops for these
cases avoids using multiplications. Finally, since only the number
of bits, not the actual value, of the maximum value is needed, the
bitwise or of all the values serves the purpose while being faster.
It is worth noting that even if overflow could happen, it was not
handled correctly anyway.
Signed-off-by: Mans Rullgard <mans@mansr.com>
The operands in both cases are 16-bit so cannot overflow a 32-bit
destination. In gain_scale() the inputs are reduced to 14-bit,
so even the shift cannot overflow.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Adding instead of subtracting the products in the loop allows the
compiler to generate more efficient multiply-accumulate instructions
when 16-bit multiply-subtract is not available. ARM has only
multiply-accumulate for 16-bit operands. In general, if only one
variant exists, it is usually accumulate rather than subtract.
In the same spirit, using the dedicated saturation function enables
use of any special optimised versions of this.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Fixed-point audio codecs often use saturating arithmetic, and
special instructions for these operations are common.
Signed-off-by: Mans Rullgard <mans@mansr.com>
The script was previously run with perl -w through the shebang
command. Now that the script is executed through direct perl invocation
the -w in the shebang command is ignored. This patch re-enables "use
warnings" whatever way the script is invoked.
Idea-By: jamal <jamrial@gmail.com>
About 30% faster on 32 bit Atom, 120% faster on 64 bit Phenom2.
This is interesting because supporting P16 is easier in e.g.
OpenGL (can misuse support for any 2-component 8 bit format),
whereas supporting p9/p10 without conversion needs a texture
format with at least 14 bits actual precision.
The shiftonly == 0 case is not optimized since the code is more
complex and the speed gain less obvious.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
It appears this function is not available everywhere
Should fix Ticket1525
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This also changes behavior as the descriptor table is more complete than
the switch/case it replaces. As well as considering all non video as
intra only
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
lavf: Detect discontinuities in timestamps for framerate/analyzeduration calculation
lavf: Initialize the stream info timestamps in avformat_new_stream
id3v2: Match PIC mimetype/format case-insensitively
configure: Rename check_asm() to more fitting check_inline_asm()
fate: Only test enabled filters
avresample: De-doxygenize some comments where Doxygen is not appropriate
rtmp: split chunk_size var into in_chunk_size and out_chunk_size
rtmp: Factorize the code by adding find_tracked_method
Conflicts:
configure
Merged-by: Michael Niedermayer <michaelni@gmx.at>
These are normally initialized to AV_NOPTS_VALUE at the start
of avformat_find_stream_info, but if a new stream is found while
this function is running (e.g. like in mpegts), the newly added
AVStreams didn't have these values properly initalized, leading
to avformat_find_stream_info terminating too soon (when the
first timestamps are far from 0).
Signed-off-by: Martin Storsjö <martin@martin.st>
Some files' embedded art seems to have the mimetype 'image/JPG' instead
of 'image/jpg'. Libav fails to parse those because it matches
case-sensitively.
Use av_strncasecmp() to fix this behaviour.
Signed-off-by: Mohammad Alsaleh <msal@tormail.org>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Fixes Ticket1627
The fate change is due to ffmpeg no longer pushing audio timestamps
aggressively up (which is what caused the AV sync issues in the ticket)
but leaving them as they are.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
