Old Mingw-w64 releases provided by some distros seemingly don't have them, so
check for them and disable the dtls protocol if unavailable.
Signed-off-by: James Almer <jamrial@gmail.com>
If the image data is not at the start of the buffer allocation, such as
when the buffer has padding before the image data, this function maps too
much memory, since src_data + src_buf->size exceeds the buffer size.
Fix this by subtracting the difference between the buffer start and the
provided image data pointer from the size of the memory range to map.
An easy way to reproduce this issue is using the vf_pad filter, which
allocates image data buffers with a nonzero offset whenever padding is
requested before the start of the image data.
The issue is that:
float en[2];
...
tns->n_filt[w] = is8 ? 1 : order != TNS_MAX_ORDER ? 2 : 3;
for (g = 0; g < tns->n_filt[w]; g++) {
tns->direction[w][g] = slant != 2 ? slant : en[g] < en[!g];
When using the AAC Main profile, n_filt = 3, and slant is by
default 2 (normal long frames), g can go above 1.
en is the evolution of energy in the frequency domain for every
band at the given window. E.g. whether the energy is concentrated
at the top of each band, or the bottom.
For 2-pole filters, its straightforward.
For 3-pole filters, we need more than 2 measurements.
This commit properly implements support for 3-pole filters, by measuring
the band energy across three areas.
Do note that even xHE-AAC caps n_filt to 2, and only AAC Main allows
n_filt == 3.
Fixes https://trac.ffmpeg.org/ticket/11418
Add check for the return value of av_malloc_array() and av_calloc()
to avoid potential NULL pointer dereference.
Fixes: dcfd24b10c ("avcodec/alsdec: Implement floating point sample data decoding")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This adds support for high bit depth formats, as well as formats with fewer
than 3 planes. The implementation for HBD is the same as for 8 bit formats,
just right shifted to 8 bits.
It's worth pointing out that this also works for HDR formats (and even DV),
because the underlying implementation is just trying to minimize the histogram
difference. If anything, using a HDR format will result in a *more* accurate
detection, because HDR formats tend to be more perceptually uniform.
Enables timeline editing options for overlay_cuda similar to what overlay allows
Example overlaying an image on a video between 30 to 60 seconds:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i sample-video.mp4 -i sample-image.jpg
-filter_complex "[1:v]hwupload_cuda[image],[0:v]scale_npp=format=yuv420p[video],[video][image]overlay_cuda=enable='between(t,30,60)'"
-c:v h264_nvenc -c:a copy -y overlay-output-gpu.mp4
Signed-off-by: Jorge Estrada <jestrada.list@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Happens since 4fc874ef08
when this code is called via error resilience.
Also do the same for wmv2dec.c.
Fixes the vsynth_{1,2,3,_lena}-mpeg4-error and wmv2-drm-dec FATE-tests.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The parameters here are not only unused, but buf_size's value
is actually wrong when flushing (it comes from the subpacket
of the last packet sent and is therefore outdated).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unused. Furthermore, this automatically fixes the issue
that init_get_bits() failure would lead to NULL + 0 (when
setting buffer_end) which is UB before C23. This happened
in the fic-avi and fic-avi-skip_cursor FATE-tests.
This saved 7296B of .text here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead of accessing unintialized data when input is shorter than
expected size.
Fixes use of uninitialized value in MSAN build.
Found by OSS-Fuzz.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Regardless of the source being an AVFMT_NOTIMESTAMPS format, if the timestamps
are generated like when using the use_wallclock_as_timestamps demuxer option,
then they are reliable.
Fixes ticket #11268
Signed-off-by: James Almer <jamrial@gmail.com>
