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>
On NVIDIA, there's a global maximum limit of approximately 112 queues,
which means it takes ONLY 7 total programs using the maximum amount of
queues to cause the driver to error out/*segfault* during initialization.
Also, each queue takes about 30ms to allocate, which quickly adds up.
This reduces the queues allocate to the minimum that we would be happy
with. Its not worth limiting decode/encode queues as they're generally
not a lot, and do help.
Commit 00b64fca55 introduced configure
detection for HAVE_POSIX_IOCTL but unfortunately this conflicts with
v4l-utils version 1.30, which itself checks for #ifdef HAVE_POSIX_IOCTL
in a public header and erroneously determines it to be true because we
define this to be 0.
Since this is only used for avdevice/v4l2, we rename this to something
else, namely ioctl_posix, simply to prevent the name conflict with the
file /usr/include/libv4l2.h at least until they can upstream a fix on
their end.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
The GetBitContext API requires the buffer to be padded, and the documentation for
av_ac3_parse_header() does not specify it, so use a temporary local buffer.
Signed-off-by: James Almer <jamrial@gmail.com>
Prevents potential null pointer dereference when querying
MaxL1ReferencesForB from codec-specific support structures
during GOP structure initialization.
Signed-off-by: Tong Wu <wutong1208@outlook.com>
GCC/Clang is smart enough to emit minss/maxss the same way as these functions.
The only theoretical benefit was in x86_32, where x87 floats are used, but the
penalty of making the clipping opaque to the compiler's scheduler plus moving
values from mmx regs to xmm and back will offset any potential speedup.
x86_32 builds targetting anything made in the last two decades and a half
should use -msse -mfp=sse anyway.
Signed-off-by: James Almer <jamrial@gmail.com>
The rtp_set_prft() function incorrectly calculates the timestamp delta
when RTP timestamps wrap around the 32-bit boundary. The current code:
delta_timestamp = (int64_t)timestamp - (int64_t)s->last_rtcp_timestamp;
treats both timestamps as large positive values, causing wraparound to
produce a large negative delta instead of the correct small positive delta.
For example, with a 90kHz video clock:
- last_rtcp_timestamp = 0xFFFFFF00 (near wraparound)
- timestamp = 0x00000100 (after wraparound)
- Current result: delta ≈ -4.3 billion ticks ≈ -47,721 seconds
- Expected result: delta ≈ +512 ticks ≈ +0.006 seconds
This causes prft->wallclock to jump backward by approximately:
- 90kHz video: ~47,721 seconds (~13.25 hours)
- 48kHz audio: ~89,478 seconds (~24.9 hours)
- 8kHz audio: ~536,871 seconds (~6.2 days)
Fix by casting the subtraction result to int32_t, which correctly
handles wraparound through modular arithmetic:
delta_timestamp = (int32_t)(timestamp - s->last_rtcp_timestamp);
This ensures the delta is always in the range [-2^31, 2^31-1], making
wraparound produce the correct small positive values.
Fixes timing jumps in applications that rely on Producer Reference Time
for media synchronization.
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows detecting changes and regressions in side data related code, same as what
framecrc does for before already for packet data itself.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Code like FFMIN(MAX_DURATION_BUFFER_SIZE, avio_size(s->pb)) is not safe
as FFMIN() is a macro and avio_size() is thus evaluated multiple
times
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
add the missing data structure pkey in the tls_context
properly set this pkey and free it
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
