Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Fixes: 45891/clusterfuzz-testcase-minimized-ffmpeg_dem_AIFF_fuzzer-6159183893889024
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: read_frame_internal() which does not return even though both demuxer and parser do return
Fixes: 43717/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5206008287330304
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reduces default fragment size from the pulse audio default of 2 sec to 50 ms.
This also has an effect on the size of the returned frames, which will be
around 50 ms as well, making timestamps more accurate.
This should fix the regression in ticket #9776.
Pulseaudio timestamps for monitor sources are still pretty inaccurate for me,
but I don't see how else should we query latencies from the library.
Signed-off-by: Marton Balint <cus@passwd.hu>
This reverts commit 7f059a250b.
Apparently adjusting latency makes a difference even if fragment size is specifed.
Signed-off-by: Marton Balint <cus@passwd.hu>
It is no longer converted since mkv_write_chapters() is called
before mkv_write_tags() which happens since commit
4ebfc13c33. Given the fact that
chapters can also be written late, mkv_write_chapters() has to
convert the metadata itself.
Fixes ticket #9812.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before this patch the muxer writes an invalid file
(namely one in which the Projection master is a child of
the Colour element) if the following conditions are met:
a) The stream contains AVMasteringDisplayMetadata without primaries
and luminance (i.e. useless AVMasteringDisplayMetadata).
b) The stream contains AV_PKT_DATA_SPHERICAL side data.
c) All the colour elements of the stream are equal to default
(i.e. unknown).
Fortunately these conditions are very unlikely to be met.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In this case it also stops pretending that the length of
the output string is somehow checked (which is currently
being done by using snprintf that is called with the amount
of space needed instead of the amount of space actually available).
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also don't allocate the string ourselves, let av_dict_set()
do it.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for using av_uuid functions directly.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by exif.c (and e.g. EXIF_TAG_NAME_LENGTH
is an implementation detail anyway).
Also remove the sentinel, as it is used in conjunction
with FF_ARRAY_ELEMS.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is more spec-compliant because it does not rely
on dead-code elimination by the compiler. Especially
MSVC has problems with this, as can be seen in
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296373.html
or
https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/297022.html
This commit does not eliminate every instance where we rely
on dead code elimination: It only tackles branching to
the initialization of arch-specific dsp code, not e.g. all
uses of CONFIG_ and HAVE_ checks. But maybe it is already
enough to compile FFmpeg with MSVC with whole-programm-optimizations
enabled (if one does not disable too many components).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: signed integer overflow: 2147483647 + 3 cannot be represented in type 'int'
Fixes: 46184/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-4678059519770624
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Its not supported to maintain a frame as receive_frame() argument
over multiple calls
Fixes: store to null pointer of type 'FFTSample' (aka 'float')
Fixes: 46231/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINKAUDIO_DCT_fuzzer-6276566037954560
Fixes: ACDC.smo
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: 536870913 * 536870913 cannot be represented in type 'int'
Fixes: 45862/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-4730373768085504
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT, SSE and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2). So given that the only systems which benefit
from the MMXEXT resamplers (which are overridden by SSE2)
are truely ancient 32bit x86s they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is a x86-32 MMXEXT implementation for resampling
planar 16bit data. multiple_resample() therefore calls
emms_c() if it thinks that this needed. And this is bad:
1. It is a maintenance nightmare because changes to the
x86 resample DSP code would necessitate changes to the check
whether to call emms_c().
2. The return value of av_get_cpu_flags() does not tell
whether the MMX DSP functions are in use, as they could
have been overridden by av_force_cpu_flags().
3. The MMX DSP functions will never be overridden in case of
an x86-32 build with --disable-sse2. In this scenario lots of
resampling tests (like swr-resample_exact_lin_async-s16p-8000-48000)
fail because the cpuflags indicate that SSE2 is available
(presuming that the test is run on a CPU with SSE2).
4. The check includes a call to av_get_cpu_flags(). This is not
optimized away for arches other than x86-32.
5. The check takes about as much time as emms_c() itself,
making it pointless.
This commit therefore removes the check and calls emms_c()
unconditionally (it is a no-op for non-x86).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This enables printing to a resource specified with -o OUTPUT.
In case the output is not specified, prints to stdout as usual.
Address issue: http://trac.ffmpeg.org/ticket/8024
Signed-off-by: Marton Balint <cus@passwd.hu>
This new function makes it possible to use avio_printf() functionality from
a function taking a variable list of arguments.
Signed-off-by: Marton Balint <cus@passwd.hu>
Namely ff_avg_h264_qpel8or16_hv1_lowpass_op_mmxext. It seems to exist
since 610e00b359 (a function like this
already existed before that commit, but it was static and
av_always_inline and was therefore not present in the actual binaries).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only ff_emulated_edge_mc_8() is used outside of lavc/videodsp.c.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This file does not use anything from get_bits.h at all;
furthermore hevcdsp.h now includes get_bits.h itself.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.
The min version requirement of 158 is applied for msvc builds only.
This is also removing the check for 'libx264 without pkg-config'
which was left for compatibility reasons about 7 years ago when
the pkg-config check was introduced by commit
e06263ef1e.
Co-authored-by: softworkz <softworkz@hotmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Matt Oliver <protogonoi@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
