Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Starting with version 4.7, gcc properly supports unaligned
memory accesses on ARM.  Not using the inline asm with these
compilers results in better code.
Signed-off-by: Mans Rullgard <mans@mansr.com>

With a dereferenced type-cast pointer as memory operand, gcc 4.6
and later will sometimes copy the data to a temporary location,
the address of which is used as the operand value, if it thinks
the target address might be misaligned.  Using a pointer to a
packed struct type instead does the right thing.

The 16-bit case is special since the ldrh instruction addressing
modes are limited compared to ldr.  The "Uq" constraint produces a
memory reference suitable for an ldrsb instruction, which supports
the same addressing modes as ldrh.  However, the restrictions appear
to apply only when the operand addresses a single byte.  The memory
reference must thus be split into two operands each targeting one
byte.  Finally, the "Uq" constraint is only available in ARM mode.
The Thumb-2 ldrh instruction supports most addressing modes so the
normal "m" constraint can be used there.
Signed-off-by: Mans Rullgard <mans@mansr.com>

The index of the motion vector has to be checked before being
multiplied by 2 for the array index.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

ModeTab.fmode has only 3 elements, so indexing it with ftype
in the initialier for 'size' is invalid when ftype == FT_PPC.

This fixes crashes with gcc 4.8.
Signed-off-by: Mans Rullgard <mans@mansr.com>

SDL only supports s16 sample format and a limited number of channel layouts.
Some versions of SDL on some systems support 4-channel and 6-channel output,
but it's safer overall to downmix any layout with more than 2 channels to
stereo.

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Reviewed-by: Mashiat Sarker Shakkhar <mashiat.sarker@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

This fixes decoding of frames which span more than two packets. Tested with
recit24.wma.
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

Indexing outside array limits is invalid and breaks with gcc 4.8.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Mans Rullgard <mans@mansr.com>

The shift parameter was removed from this interface in 7e1ce6a6.
This updates the Altivec implementation to match.
Signed-off-by: Mans Rullgard <mans@mansr.com>

To load unaligned vector data in the usual way, explicit vec_ld()
should be used rather than dereferencing a pointer to a vector type.
When the VSX extension is enabled, gcc may compile vector pointer
dereferences using the VSX lxvw4x instruction instead of the lvx
instruction typically used with Altivec/VMX.  As the behaviour of
these instructions with unaligned addresses differs, it is important
that only lvx is used here.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Allowing dsputil functions to assume the stride is a multiple of 16
even for smaller block sizes can simplify their implementation.
This appears to be the only place this guarantee is not met.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Do return error if memory allocation or I/O fails.

Do not return 0 on error.

Non perceptual color model that aims to have an increase effectiveness
in compression like the normal YCbCr while having near-lossless/lossless
mapping to RGB.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Apply coding style to the structs.

Required because it's used in a call to imdct_half(), which is an AVX
function.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Indexing outside arrays is invalid and breaks with gcc 4.8.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Down from 95 kcycles to 93 (including all called functions).
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Force-inlining increases object size by 8kB and causes a 2% slowdown.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

is_block2 was always 0, so just remove it, and change accordingly the code.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

120->100 cycles.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Commit 356ee8d7 caused the initial inversion.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

141 cycles down to 51.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

This adds a hand-optimized assembly version for get_cabac much like the
existing one, but it works if the table offsets are RIP-relative.
Compared to the non-RIP-relative version this adds 2 lea instructions
and it needs one extra register. get_cabac() gets about 40% faster, for
an overall speedup of about 5%.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

The reason is this is easier for PIC code (in particular on darwin...).
Keep the old names as pointers (static in cabac_functions.h so gcc
knows these are just immediate offsets) so the c code can nicely stay the same
(alternatively could use offsets directly in the functions needing the
tables). This should produce the same code as before with non-pic and better
code (confirmed) with pic.

The assembly uses the new table but still won't work for PIC case.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

As pointed by Paul B Mahol <onemda@gmail.com> the previous code could
lead to null pointer dereference.

Its behaviour in line with ffurl_close(NULL).

Skip to parse fields for additional independent substreams and its
associated dependent substreams since libavcodec's E-AC-3 decoder does not
support them yet.
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>