Mans Rullgard [Mon, 2 Jul 2012 00:59:04 +0000 (01:59 +0100)]
flacdec: simplify sample buffer handling
Pass pointer to sample buffer instead of channel number to various
functions called from decode_subframe(). Also simplify a few
expressions within this function.
Jan Ekström [Mon, 20 Aug 2012 18:16:42 +0000 (21:16 +0300)]
fate: make Ut Video encoder tests use bitexact swscale flags
The failures on various architectures and compilers on the RGB(A)
tests seem to have been because of one-off YCbCr->RGB conversion
results. This should make the conversion results match on most if
not all code paths.
Uoti Urpala [Tue, 7 Aug 2012 11:48:06 +0000 (14:48 +0300)]
h264: vdpau: fix crash with unsupported colorspace
The h264_vdpau decoder crashed if output colorspace was not 8-bit 420.
Add a check to error out instead (current hardware does not support
other colorspaces, so successful decoding is not possible).
Mans Rullgard [Wed, 15 Aug 2012 23:10:33 +0000 (00:10 +0100)]
configure: clean up Altivec detection
There used to be one test for Altivec intrinsics support and a
separate test to determine which of two possible syntaxes to use
for vector literals. Since 2008, we only support the more common
of these so the split test no longer makes sense.
This combines the tests into one and also changes the hard error on
failure to a warning. The test can reasonably fail if no --cpu flag
is provided (or is provided with an unknown CPU) and the compiler
default target does not support Altivec. Aborting in this case is
probably over-reacting.
Samuel Pitoiset [Mon, 13 Aug 2012 15:05:00 +0000 (17:05 +0200)]
rtmp: Add support for SWFVerification
Specifies how the server verifies client SWF files before allowing the
files to connect to an application. Verifying SWF files is a security
measure that prevents someone from creating their own SWF files that can
attempt to stream your resources.
Samuel Pitoiset [Sat, 11 Aug 2012 10:41:33 +0000 (12:41 +0200)]
rtmp: Do not send _checkbw calls as notifications
The _checkbw calls were changed to use transactionId 0 in commit 82613564 so that servers would not return _result/_error about it.
While this is the strict interpretation of the spec, there are
servers that return _error about it, even if transactionId was 0.
The latest version of EvoStream Media Server (the commercial version
of crtmpserver) behaves properly as described, i.e. returning an
_error normally but not returning anything when using transactionId
0. The latest version of crtmpserver (right now at least) doesn't
behave like this though, it returns an error even if transactionId
was 0.
There are also other servers that return errors even if transactionId
is set to 0. Therefore set a proper transaction id so that the invoke
can be tracked and the error properly ignored instead.
Mans Rullgard [Mon, 13 Aug 2012 22:03:37 +0000 (23:03 +0100)]
g723.1: simplify normalize_bits()
This function is always called with a non-negative argument, so
those special cases are not needed. In the places the argument
might be zero, the return value for a zero argument does not matter
since it would then be used to scale an array full of zeros.
Mans Rullgard [Sun, 12 Aug 2012 23:53:05 +0000 (00:53 +0100)]
x86: swscale: fix fragile memory accesses
To access data at multiple fixed offsets from a base address, this
code uses a single "m" operand and code of the form "32%0", relying on
the memory operand instantiation having no displacement, giving a final
result of the form "32(%rax)". If the compiler uses a register and
displacement, e.g. "64(%rax)", the end result becomes "3264(%rax)",
which obviously does not work.
Replacing the "m" operands with "r" operands allows safe addition of a
displacement. In theory, multiple memory operands could use a shared
base register with different index registers, "(%rax,%rbx)", potentially
making more efficient use of registers. In the cases at hand, no such
sharing is possible since the addresses involved are entirely unrelated.
After this change, the code somewhat rudely accesses memory without
using a corresponding memory operand, which in some cases can lead to
unwanted "optimisations" of surrounding code. However, the original
code also accesses memory not covered by a memory operand, so this is
not adding any defect not already present. It is also hightly unlikely
that any such optimisations could be performed here since the memory
locations in questions are not accessed elsewhere in the same functions.
Mans Rullgard [Sun, 12 Aug 2012 18:45:46 +0000 (19:45 +0100)]
x86: yadif: fix asm with suncc
Under some circumstances, suncc will use a single register for the
address of all memory operands, inserting lea instructions loading
the correct address prior to each memory operand being used in the
code. In the yadif code, the branch in the asm block bypasses such
an lea instruction, causing an incorrect address to be used in the
following load.
This patch replaces the tmpX arrays with a single array and uses a
register operand to hold its address. Although this prevents using
offsets from the stack pointer to access these locations, the code
still builds as 32-bit PIC even with old compilers.
Mans Rullgard [Sun, 12 Aug 2012 01:18:41 +0000 (02:18 +0100)]
x86: cabac: allow building with suncc
This fixes two issues preventing suncc from building this code.
The undocumented 'a' operand modifier, causing gcc to omit a $ in
front of immediate operands (as required in addresses), is not
supported by suncc. Luckily, the also undocumented 'c' modifer
has the same effect and is supported.
On some asm statements with a large number of operands, suncc for no
obvious reason fails to correctly substitute some of the operands.
Fortunately, some of the operands in these statements are plain
numbers which can be inserted directly into the code block instead
of passed as operands.
With these changes, the code builds correctly with both gcc and
suncc.
Mans Rullgard [Sun, 12 Aug 2012 01:08:46 +0000 (02:08 +0100)]
x86: mlpdsp: avoid taking address of void
This code contains a C array of addresses of labels defined in
inline asm. To do this, the names must be declared as external
in C. The declared type does not matter since only the address is
used, and for some reason, the author of the code used the 'void'
type despite taking the address of a void expression being invalid.
Changing the type to char, a reasonable choice since the alignment
of the code labels cannot be known or guaranteed, eliminates gcc
warnings and allows building with suncc.
Mans Rullgard [Sat, 11 Aug 2012 20:00:21 +0000 (21:00 +0100)]
g723.1: do not bounce intermediate values via memory
Although a reasonable compiler will probably optimise out the
actual store and load, this operation still implies a truncation
to 16 bits which the compiler will probably not realise is not
necessary here.
Mans Rullgard [Sat, 11 Aug 2012 18:59:08 +0000 (19:59 +0100)]
g723.1: avoid saving/restoring excitation
Writing the scaled excitation to a scratch buffer (borrowing the
'audio' array) instead of modifying it in place avoids the need
to save and restore the unscaled values.
Mans Rullgard [Sat, 11 Aug 2012 00:52:10 +0000 (01:52 +0100)]
g723.1: use saturating addition functions
Use saturating addition functions instead of 64-bit intermediates
and separate clipping. This is much faster when dedicated
instructions are available.
Mans Rullgard [Fri, 10 Aug 2012 17:15:41 +0000 (18:15 +0100)]
g723.1: optimise scale_vector()
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.
Mans Rullgard [Fri, 10 Aug 2012 15:42:54 +0000 (16:42 +0100)]
g723.1: remove useless uses of MUL64()
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.