With a complex FFT instead of real FFT, the negative frequencies
are not dropped from the spectrum output, so they need to be scaled
when the positive frequencies are scaled. The location of the top
bin is also different.
Signed-off-by: Jason Jang <jcj83429@gmail.com>
In previous state, a new frame was allocated on each timestamp step,
i.e. each frame/field transition. However, for interlace, a new frame
should be allocated on 1st field, completed with the 2nd and finally
freed.
This commit fixes the frame allocation and the detection of missing RTP
markers.
Signed-off-by: Patrick Keroulas <patrick.keroulas@radio-canada.ca>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
The fdk-aac decoder can return decoded audio data with a delay.
(Whether it does this or not depends on the options set; by default
it does add some delay.) Previously, this delay was handled by
adjusting the timestamps of the decoded frames, but the last delayed
samples weren't returned.
Set the AV_CODEC_CAP_DELAY flag to indicate that the caller should
flush remaining samples at the end. Also trim off the corresponding
amount of samples at the start instead of adjusting timestamps.
Signed-off-by: Martin Storsjö <martin@martin.st>
At present, side data printing forces display for all levels i.e.
stream, packets and frames. This can bloat output and also force
decode of all frames in selected streams.
Now, stream_side_data[=type], packet_side_data[=type] &
frame_side_data[=type] can be used with -show_entries to specify carrier
element.
VkPhysicalDeviceVulkan12Features isn't implemented on MoltenVK yet.
VkPhysicalDeviceTimelineSemaphoreFeatures is less versatile but
simple. None of device_features_1_1 nor device_features_1_2 has real
usage yet, keep the code for future.
We still own it on failure, and there's no point trying to feed it again.
This should address the issue reported in dav1d #383 and part of VLC #26259.
Signed-off-by: James Almer <jamrial@gmail.com>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Fixes: signed integer overflow: -9223372036854775808 - 8 cannot be represented in type 'long'
Fixes: 43542/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5237670148702208
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 15244032 * 256 cannot be represented in type 'int'
Fixes: 43504/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-4865014842916864
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
av_dict_set() with AV_DICT_DONT_STRDUP_VAL takes ownership
of the string it is passed to as val; this includes freeing it
on error.
Fixes Coverity issue #1497468.
Reviewed-by: Eran Kornblau <eran.kornblau@kaltura.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
following 625ea2d, redirect caching is performed according to the http
response headers, there's no need to have it as an option -
always start from the original uri, and apply any redirects according
to the redirect_cache dictionary.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Since e1027aba68,
ALLOW_INTERLACED is no longer defined in h264_ps.c,
leading to a warning when encountering an SPS compatible
with MBAFF. This warning was always nonsense, because
ff_h264_decode_seq_parameter_set() is also used by the parser
and it makes no sense for the parser to warn about missing
decoder features; after all, it is not a parser's job
to warn when a feature is unsupported by a decoder
(and in this case it is even weirder, because even if the H.264
decoder is disabled, the warning will only be shown for MBAFF
sequence parameter sets). So remove the warning in h264_ps.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
use_intra_dc_vlc is currently kept in sync between frame threads
in mpeg4_update_thread_context(), yet it is set when decoding
blocks, i.e. after ff_thread_finish_setup(). This is a data race
and therefore undefined behaviour.
This race can be fixed easily by moving the variable from the context
to the stack: use_intra_dc_vlc is only read in
mpeg4_decode_block() and only if one is decoding an intra block.
There are three callsites for this function: One in
mpeg4_decode_partitioned_mb() which always sets use_intra_dc_vlc
before the call and two in mpeg4_decode_mb(). One of these callsites
is for intra blocks and use_intra_dc_vlc is set before it;
the last callsite is for non-intra blocks, where use_intra_dc_vlc
is ignored. So if it is used, it always uses a new value and can
therefore be moved to the stack.
The above also explains why this data race did not lead to
FATE-test failures.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
An offset has the advantage of not needing to be updated
when the buffer is reallocated. Furthermore, the way the pointer
is currently updated is undefined behaviour in case the pointer
is not already set (i.e. when not encoding MPEG-1/2), because
it calculates the nonsense NULL - s->pb.buf.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also use said function in mpegvideo.c and mpegvideo_enc.c;
and make ff_free_picture_tables() static as it isn't needed anymore
outside of mpegpicture.c.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that dealing with the Simple Studio Profile
has been moved to mpeg4videodec.c. It also allows to avoid
allocations, because one can simply put the required buffers
on the context (if one made these buffers part of MpegEncContext,
the memory would be wasted for every codec other than MPEG-4).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The sample mpeg4/mpeg4_sstp_dpcm.m4v existed in the FATE-suite,
but it was surprisingly unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In this case the macroblocks written to are smaller, yet
the MPEG-4 Simple Studio Profile code for 10bit DPCM ignored this;
e.g. in case of lowres = 2 or = 3, the sample mpeg4_sstp_dpcm.m4v
from the FATE-suite reads beyond the end of the buffer.
This commit fixes this by taking lowres into account.
The DPCM macroblocks of the aforementioned sample look
as good as can be expected after this patch; yet the non-DPCM
coded macroblocks are simply corrupt.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
