Compared to av_opt_ptr, accessors bring:
- better performance (negligible);
- compile-time type check;
- link-time existence check
(or at worst, a dynamic linker error instead of a NULL dereference).
Progressive data is allocated later in decode_sof(), not allocating
that data leads to NULL dereferences.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
This prevents sample_rate/data_length from going negative, which
caused various crashes and undefined behaviour further down.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
This properly synchronizes frame size changes between threads if
subsequent threads abort decoding before frame size is initialized, i.e.
it prevents the thread after that from ping-ponging back to the original
value.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
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>
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>
The shift parameter was removed from this interface in 7e1ce6a.
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>
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>
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.
There is a surprisingly large performance improvement over the c version (more
so than the generated assembly seems to suggest) just in get_cabac, I measured
roughly 40% faster for get_cabac on a K8. However, overall the difference is
not that big, I measured roughly 5% on a test clip on a K8 and a Core2.
Hopefully it still compiles on x86 32bit...
Now that only one table is used, there's some chance even darwin as compiles
this (apparently the label arithmetic used previously doesn't work if it
involves symbols defined in a different file, thanks to Ronald S. Bultje for
helping me with this).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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: Michael Niedermayer <michaelni@gmx.at>
not used outside the cabac test functions (which probably means it's
a bad test if it doesn't use the same tables as the real functions?)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>