* commit '780cd20b00a69e26bbfffbb8eec16fbe999ea793':
aarch64: Use .data.rel.ro for const data with relocations
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f963f80399deb1a2b44c1bac3af7123e8a0c9e46':
arm: Use .data.rel.ro for const data with relocations
Conflicts:
configure
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This test doesn't cover every possible issue with this function.
It covers options management only.
Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
* commit '6fd91fa11909f27902498648680dbb3d13f1f175':
h264: increase MAX_SLICES to 32
The available sample decodes correctly before, but the reporter of the bug
claims that this change reduces artifacts. This is thus merged
If someone has samples that decode differently depending in the MAX_SLICES
value, please open a ticket on trac.
Also this change should be reverted if it turns out that the artifacts
that where seen had a different cause
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This fixes artifacts in the last pixel of rows with some widths and pixel formats
Found-by: Dominique Leroux <Dominique.Leroux@autodesk.com>
Tested-by: Dominique Leroux <Dominique.Leroux@autodesk.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
According to the DPX file format description found at
http://www.fileformat.info/format/dpx/egff.htm the ImageElement part of
the GenericImageHeader also contains an an offset to the real image data
beside the same member that can be found in the GenericFileHeader.
Libav keeps this member empty (=0) while some applications expects it to
be filled properly. FATE test updated accordingly.
Bug-Id: 742
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit 'b280c6202b28b371a8d96850194fd69d7ad5dcc0':
arm: fft_vfp: Unify the behaviour in ff_fft_calc_vfp between arm/thumb
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ae81576414f2d2083d3118fb4abe1ebc5a7a4c54':
arm: fft_vfp: Add a missing "endconst" when building in thumb mode
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Don't include the function pointer table in the code segment
in arm mode.
This shouldn't have any significant performance effect. It does
end up as a few more instructions than before, for ARM, but
only at the entry to this function, not within the fft functions
themselves.
Signed-off-by: Martin Storsjö <martin@martin.st>
We dont fail hard if its not set as the old API allowed this and our examples
did in the distant past not set it, these examples still work with the
current code and some encoders.
Based on suggestion by: funman
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This code only segfaults and fixing the segfault, the resulting
files are unplayable, so disable to avoid the segfault.
Better solution is welcome
See: [FFmpeg-devel] [PATCH] avcodec/libxavs: remove global header code
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b72727a5248f1ef02db99b378dce1eb48a46357a':
lavc: mention that the parser callback never returns an error
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3a56bcee7cb7549b2813e39ce3bee3b7c522aecb':
mpeg12dec: Use more specific error codes
Conflicts:
libavcodec/mpeg12dec.c
See: 1852b2a0f4
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e0bb74a1403ed77ef369b9d62866f8a4afaf3f1d':
exr: Add a gamma flag to exr loader to avoid banding
Conflicts:
libavcodec/exr.c
See: cd3daad77e
Merged-by: Michael Niedermayer <michaelni@gmx.at>
libxvidcore calculate number of threads basing on video height.
If height is small enough it allocates 0 bytes long memory and
writes to it.
Setting thread_count to 0 uses 1 thread and skips bugged code.
Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The "faulty" samples actually sound fine when ignoring this issue.
For ticket #3886, more samples are decoded.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Rely on the way memcpy is optimized for one's system instead of looping
on a byte buffer for buffer copies to handle P frames.
Tested-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
