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>
codec31/32 are similar to codec1/3 (RLE coding) but with two 4-bit pixels
per byte; they are only used in the Sega-CD release of Rebel Assault 1.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Some of the calculated values were wrong and/or assigned
to the wrong pixel of the 4x4 block.
Found during testing with Rebel Assault Sega-CD release.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
it has a bug and its effects aren't that noticeable, esp. with
the smoothing applied to the whole picture by modern video display
engines.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
The iirfilter is only used in its test tool since
01ecb7172b which
stopped using it in AAC, its only user.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also "fixes" the inverted order of arguments in the av_malloc_array()
calls and therefore part of ticket #11620.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Just do it like av_frame_replace().
Also "fixes" the swapped order or arguments to av_malloc_array()
(the first is supposed to be the number of elements, the second
the size of an element) and therefore part of ticket #11620.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(I don't know whether this can be triggered for a file with
nonnegative channel count, given that src's extended data can't
have been allocated in this case.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(Some more options could be set via this method
if the order in which the options are applied doesn't matter.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
As described in section F.6.1 from ETSI TS 102 366.
Found-by: nyanmisaka
Reviewed-by: Baptiste Coudurier <baptiste.coudurier@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
We were using a mix of pointers to local variables read via AV_RL32/64 and
pointers directly to the texture buffer as keys to interact with the lookback
hashtables. On big-endian systems, these produced different values. This change
makes all hashtable interactions use direct pointers to the texture buffer and
only invokves AV_RL32 in the event of a lookback hashtable miss.
Signed-off-by: Emma Worley <emma@emma.gg>
