api doc: https://docs.openssl.org/1.0.2/man3/BIO_s_mem
In higher versions (openssl 1.0.2 and higher),
the function signature is BIO *BIO_new_mem_buf(const void *buf, int len),
so passing a const string doesn't cause an warnings.
However, in lower versions of OpenSSL,
the function signature becomes BIO *BIO_new_mem_buf(void *buf, int len),
which leads to warnings.
OpenSSL guarantees that it will not modify the string,
so it's safe to cast the pem_str to (void *) to avoid this warning.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This was requested by users of `vf_libplacebo`, to mirror the existing
option on the other `vf_scale_*` family of filters. While we have
`vf_normalize`, it was not as useful in the event that the content
stretching was actually desired.
Bridges an important usability gap between `vf_scale` and `vf_libplacebo`
that made mixing and matching the filters needlessly difficult.
This aligns the behavior of vf_libplacebo with other filters in the
vf_scale family, that forward any change in the SAR as a result of
changing the output resolution to the output frame / link, and updates
the ff_scale_adjust_dimensions() call to continue working as intended.
The new behavior reflects the documentation of vf_libplacebo, which
described this behavior despite that not being the way the filter worked
up to this point.
As an aside, also fixes a bug where the AVFrame SAR was inconsistent
with the AVFilterLink SAR when the s->nb_inputs > 1 condition was met.
Under normal circumstances, this change does not affect anything, as the vast
majority of filters either support only vulkan or only software formats.
However, when a filter supports both (such as vf_libplacebo itself, and
possibly vf_scale in the future), linking together two such filter instances
without an explicit format will default matching the input format, resulting
in a redundant round trip through host RAM.
This change bumps up AV_PIX_FMT_VULKAN to the first entry in the format list,
ensuring that it gets preferred whenever possible.
When running plain "cl", to get the MSVC version, it prints the
version header on stderr, while the usage instructions are printed
on stdout. Usually, the version on stderr gets flushed first,
so "head -n1" gets the line it expects, but some times (in particular
when running MSVC wrapped in wine), it can get the usage line
first.
Redirect stdout to /dev/null, so we only grab the version among
the lines printed to stderr. This should make the version number
grabbing more robust.
At least all relevant versions of MSVC seem to print this specifically
to stderr, not stdout (so we don't risk to miss it); checked down
to MSVC 2010.
Signed-off-by: Martin Storsjö <martin@martin.st>
In sbg_read_header(), if avformat_new_stream() failed, it returns
without cleanup, which may cause memory leaks. Replace return statement
with goto so that we would first clean up then return.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: James Almer <jamrial@gmail.com>
Changed the minimum required version of liboapv from 0.1.13 to 0.1.13.1
Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>
Signed-off-by: James Almer <jamrial@gmail.com>
LLVM tools print installation path upon execution. If one uses LLVM
tools bundled with Microsoft Visual Studio installation, they would be
incorrectly detected as Microsoft's ones.
Microsoft tools can have localized names, so a more specific string
check is not feasible, but luckily we can test if "Microsoft" is at the
beginning of the line, as it is always the case.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Tests both the Media 100 decoder (using the media100_to_mjpegb BSF
implicitly) as well as using said BSF, followed by the MJPEGB decoder.
(We currently hit a bug when remuxing: The demuxer treats compressorname
as encoded in a Mac character encoding (Mac OS Roman?) and converts
it to UTF-8, yet the muxer just writes it.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise the extradata used would be ISOBMFF if the input is
even though we use the *_mp4toannexb BSFs to convert it to
annex B to feed it to the actual decoder.
(The mediacodec decoders also use said BSFs, yet they process
the extradata in a way that works even when using the ISOBMFF
extradata; in fact, using the converted extradata would break
their check for whether to warn for missing extradata for
the ISOBMFF without-in-band-header profiles.
Furthermore, there are several users of the *_mp4toannexb BSFs
that don't ever touch extradata. They have not been touched.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This reverts commit 1c17061397.
The commit intended to provide certain codecs using *_mp4toannexb
bitstream filters with updated (annex B) extradata (even when
the user-supplied one was ISOBMFF), yet BSFs are allowed to change
way more. The media100_to_mjpegb BSF used by the media100 decoder
changes the codec id; the commit being reverted therefore changed
AVCodecContext.codec_id which is an API violation and broke
media100 decoding with the FFmpeg cli tool.
This commit also made changes from the internal BSF externally
visible. extradata is documented to be "owned by the codec and
freed in avcodec_free_context()" which does not include replacing
it with something else in avcodec_open2() and may surprise users
who think that AVCodecContext.extradata is immutable before
avcodec_free_context(). It also incurred a memdup which is completely
unnecessary for most decoders.
Therefore this commit is reverted. The problem it tried to solve
will be solved differently in the next commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When chroma subsampling is in use, the filter averages
the corresponding (non subsampled) alpha values to get
the actual alpha value. When vertical subsampling is
in use, the next line is accessed via a[src->linesize[3]],
yet a is an uint16_t* for >8 bit formats and linesize
is always in bytes, so that this actually uses the second
line below the current one. This is fixed in this commit.
No FATE test needed updates, because the filter-overlay-yuv420p10
and filter-overlay-yuv444p10 tests use a yuv420p test file
that has constant opacity after conversion to yuva.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Just keep the pointers for the beginning of a line uint8_t*
and use uint16_t* to do the actual processing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This happens when the pixel format of the output does not
have an alpha channel. It leads to FATE failures with
the ffmpeg-filter_colorkey, filter-overlay-dvdsub-2397
filter-overlay,
filter-overlay_{gbrp_gbrap,nv12,nv21,yuv420,yuv420_yuva420,
yuv420p10,yuv422_yuva422,yuv422p10,yuv444_yuva444,yuv444p10}
and sub2video tests when using Clang UBSan.
Fix this by only performing the pointer arithmetic when
it is going to be used. This can be checked via variables
that compile-time constants due to inlining, so that the
checks are free. Given that the pointer is potentially
used as a function argument, the compiler could elide
the calculation, but not it can. The size of .text decreased
by 1632B with GCC 14 and by 1392B with Clang 19 (both -O3).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This otherwise generates an inconsistency between the frame state and the
link state, since the link state is set to 1:1 explicitly when `reset_sar`
is enabled, but this line of code unconditionally overwrote the output
frame SAR with the value that would be computed in the absence of `reset_sar`.
cf. vf_scale_cuda, which does this correctly
The segment_duration must not be set to zero when writing the moov
atom for the second time. This is related to edit lists in standard
MP4 files.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
In libavformat/rtmpproto.c:gen_connect(), if check on string length
or check on codec fourcc failed, ff_rtmp_packet_create() allocated
data in pkt would leak. Add ff_rtmp_packet_destory before return error
code.
Signed-off-by: Lidong Yan <502024330056@smail.nju.edu.cn>
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is useful for tests that compare dctcoefs which will be either 2 bytes or
4 bytes, depending on bitdepth.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When seeking on multi-angle titles, libdvdnav does not lock on
to the correct sectors initially as it seeks to find the right NAV packet.
This manifests itself as two bugs:
(1) When seeking on the first angle in a multi-angle segment,
frames from another angle will appear (for example in intro
or credits scenes). This issue is present in VLC also.
(2) When seeking during a segment on angle n+1, the demuxer
cannot deduce the right position from dvdnav and does not allow
seeking within the segment (due to it maintaining a strict state).
Correct the issue by switching to angle 1 before doing the seek
operation, and skipping 3 VOBUs (NAV packet led segments) ahead
where dvdnav will have positioned itself correctly.
Reported-by: Kacper Michajlow <kasper93@gmail.com>
Signed-off-by: Marth64 <marth64@proxyid.net>
Just applying some UX polish.
This is to match the lowercase trend of attributes in
the dump string (and similar to chapters).
Signed-off-by: Marth64 <marth64@proxyid.net>
Change delta_timestamp to int32_t and add explicit cast to handle
RTP timestamp wraparound correctly. This fixes implementation-defined
behavior when computing negative timestamp differences due to 32-bit
wraparound.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes building with Clang in MSVC mode, for x86, which was
broken in 6e49b86996 (in Nov 2024);
previously it failed with undefined symbols for the constants
defined with DECLARE_ASM_CONST, accessed via inline assembly.
Before 57861911a3, there was an
#elif defined(__GNUC__) || defined(__clang__)
case before the
#elif defined(_MSC_VER)
case for defining DECLARE_ASM_CONST, which included av_used.
(This case included the explicit "defined(__clang__)" since
f637046d3134a331e4b5a7243ac3dfb92735b8a5.)
After 57861911a3, it used the
generic definition of DECLARE_ASM_CONST that also included
av_used - which also worked for Clang in MSVC mode. But after
6e49b86996, Clang in MSVC mode
ended up using the MSVC specific variant which lacked the
av_used declaration, causing linker errors due to undefined
symbols.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fix incorrect enum value used in color primaries check by replacing
AVCOL_SPC_UNSPECIFIED with AVCOL_PRI_UNSPECIFIED.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
While the current code iterated over the messages, it always returned
in the first iteration. Instead keep iterating and warn for failure to
parse. At time of writing, none of the parsing functions seems to
actually return an error, ever.
Fix CID 1648348
When checking for filmgrain here, needs_fg can be true even when
film_grain_characteristics is NULL (when aom_film_grain.enable is true),
therefore this check could end up dereferencing film_grain_characteristics
even though it is NULL.
Fix CID 1648347
Fixes use of bultins on clang x86_64-pc-windows-msvc which does not
define any __GNUC__. Also on other targets __GNUC__ is defined to 4 by
default, so any feature testing based on version is not really valid.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
