This is not a real error and memsetting always even when the
size did not change is overkill, but it still should be
an acceptable trade-off.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
* qatar/master:
sgidec: Use bytestream2 functions to prevent buffer overreads.
cosmetics: Move static and inline attributes to more standard places.
configure: provide libavfilter/version.h header to get_version()
swscale: change yuv2yuvX code to use cpuflag().
libx264: Don't leave max_b_frames as -1 if the user didn't set it
FATE: convert output to rgba for the targa tests which currently output pal8
fate: add missing reference files for targa tests in 9c2f9b0e2
FATE: enable the 2 remaining targa conformance suite tests
targa: add support for rgb555 palette
FATE: fix targa tests on big-endian systems
Conflicts:
libavcodec/sgidec.c
libavcodec/targa.c
libswscale/x86/output.asm
tests/fate/image.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
At the very least this should fix warnings about unused static
functions if one or more of these is not defined.
However even compilation might be broken if the compiler does
not optimize the function away completely.
This actually happens in case of the AVX function, since the
function pointer is used in an assignment that is not under
an #if and thus probably only optimized away after the function
was already marked as used.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
We do this for all other codec_tag checks in mpegvideo*/h26*
doing it here too makes the code more consistent.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
While we correctly "register" the side data when we split it,
the application (in this case FFmpeg) might not update the
AVPacket pool it uses to finally free the packet, thus
causing a leak.
This also makes the av_dup_packet unnecessary which could
cause an even worse leak in this situation.
Also change the code to not modify the user-provide AVPacket at all.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
* cus/stable:
ffplay: silence buffer size must be a multiple of frame size
ffplay: use swr_set_compensation for audio synchronization
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
FATE: add tests for targa
ARM: fix Thumb-mode simple_idct_arm
ARM: 4-byte align start of all asm functions
rgb2rgb: rgb12to15()
swscale-test: fix stack overread.
swscale: fix invalid conversions and memory problems.
cabac: split cabac.h into declarations and function definitions
cabac: Mark ff_h264_mps_state array as static, it is only used within cabac.c.
cabac: Remove ff_h264_lps_state array.
Conflicts:
libswscale/rgb2rgb.h
libswscale/swscale_unscaled.c
tests/fate/image.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Some of these encoders may produce invalid bitstreams, which should not
be done without the user knowing.
Some of these decoders may be unfinished and may contain security issues.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
max_b_frames is initialized to -1 for libx264, to allow
distinguishing between an explicit user set 0 and a default not
touched 0 (see bb73cda2).
If max_b_frames is left as -1, this affects dts generation (where
expressions like max_b_frames != 0 are used), so make sure it is
left at the default 0 after the libx264 init function returns.
This avoids unnecessarily producing dts != pts when using
profile=baseline.
Signed-off-by: Martin Storsjö <martin@martin.st>
The alignment directive must obviously precede the label.
This was never noticed in ARM mode since the location is
already aligned there.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Due to apprent bugs in the GNU assembler and/or linker, relocations
can be incorrectly processed if the alignment of a Thumb instruction
is changed in the output file compared to the input object.
This fixes crashes in h264 decoding with Thumb enabled. No effect in
ARM mode since everything is 4-byte aligned there.
Signed-off-by: Mans Rullgard <mans@mansr.com>
