| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
Found-by: gcc5-ubsan.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The original code left-shifts negative values, which is undefined
in the C99 specification (the one used during normal Libav compilation).
This change multiplies by (1 << shift), which is functionally equivalent,
but has defined behavior.
With this change, fate-idct8x8 compiled with --fsanitize=undefined works.
Bug-Id: 686
|
| |
|
|
|
|
|
|
| |
Remove the duplicated code for handling failure of apply_param_change().
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
|
|
|
|
| |
Rename luma table to delta table and change how it is used.
CC: libav-stable@libav.org
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
|
|
|
| |
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The plugin loaded may not match the general implementation capability
wise.
|
|
|
|
|
| |
It currently just calls av_init_packet(), which does not touch those
fields.
|
| |
|
|
|
|
| |
This avoids accessing NULL pointers in case of error.
|
|
|
|
|
| |
The deinit function in the 'error' section will correctly free
everything.
|
| |
|
| |
|
| |
|
|
|
|
| |
The reasoning is the same as for the corresponding qsvenc patch.
|
|
|
|
|
|
|
|
| |
The QSV runtime expects the sync point address passed to
MFXVideoENCODE_EncodeFrameAsync() to be valid until
MFXVideoCORE_SyncOperation().
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
| |
AVCodecParameters
|
|
|
|
|
|
| |
This API is intended to allow passing around codec parameters without
using full AVCodecContext (which also contains codec options and
encoder/decoder state).
|
|
|
|
|
| |
Some optimized functions reference optimized symbols, so the functions
must be explicitly disabled when those symbols are unavailable.
|
|
|
|
|
| |
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
|
|
|
| |
Sample-Id: asan_heap-uaf_3660f67_757_cov_1257014655_Hi422FR1_SONY_A.jsv
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
|
| |
First check the context, then check internal option. Drop the ! typo.
Introduced in 60f0fde3092d18d4d36555962c192af8691a099c.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The WTV demuxer depends on large parts of the MPEG-TS demuxer internals
anyway and fails to build without it.
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
| |
|
| |
|
| |
|
|
|
|
| |
Needed for enum AVCodecID
|
|
|
|
| |
Also fix #endif comments in the FFT init code.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today, we track the short term RPS size for DXVA, but only if the
SliceHeader RPS is being used. Otherwise it's left uninitialized.
NVIDIA's VDPAU implementation requires that the size be accurately
tracked even if an SPS RPS is being used. In this case, it's really
counting the size of the RPS idx information, but you end up with
mangled output if the value is not accurate.
VDPAU also needs the size of the long term RPS.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
ucNumDeltaPocsOfRefRpsIdx needs to contain the flat value from the SPS RPS,
and not the final computed value from the slice header RPS, as this calculation
is done internally by the driver again.
Sample-Id: http://trailers.divx.com/hevc/Sintel_4k_27qp_24fps_1aud_9subs.mkvi
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
|
|
|
|
|
| |
This function copies the encoded bistream into the caller's packet,
calling it 'get_frame' is misleading.
|
|
|
|
|
| |
An input frame always corresponds to exactly one output packet, so there
is no point in complicating the situation by managing them separately.
|
| |
|
|
|
|
|
| |
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|