| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
|
|
|
|
| |
Fixes: signed integer overflow: 2147483610 + 52 cannot be represented in type 'int'
Fixes: 23260/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PBM_fuzzer-5187871274434560
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
Fixes: left shift of 1913647649 by 1 places cannot be represented in type 'int'
Fixes: 23572/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-5082619795734528
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
| |
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
|
|
| |
Fix comment for avpriv_dict_set_timestamp from b72a7b96f84
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These functions have a terrible design, let us fix them before extending
them.
First design mistake: no error code. A helper function for testing
memory allocation failure where AVERROR(ENOMEM) does not appear is
absurd.
Second design mistake: printing a message. Return the error code, let
the caller print the error message.
Third design mistake: hard-coded use of goto.
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262544.html
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
| |
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
| |
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
|
|
|
|
|
|
|
| |
The format is packed RGB with each channel 10 bits available and
include 2 bits unused.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
|
|
|
|
| |
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
|
|
|
| |
Use opaque iteration state instead of the previous child class. This
mirrors similar changes done in lavf/lavc.
Deprecate the av_opt_child_class_next() API.
|
|
|
|
| |
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
| |
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
| |
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
| |
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
| |
It's better to not mix user provided flags and internal flags set by
AVBufferRef helper functions.
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
| |
av_buffer_pool_init2() may be NULL
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
| |
av_buffer_pool_init2()
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
make checkheaders will get error as follow:
CC libavutil/hwcontext_vulkan.h.o
In file included from libavutil/hwcontext_vulkan.h.c:1:
./libavutil/hwcontext_vulkan.h:130:23: error: ‘AV_NUM_DATA_POINTERS’ undeclared here (not in a function)
130 | void *alloc_pnext[AV_NUM_DATA_POINTERS];
| ^~~~~~~~~~~~~~~~~~~~
./libavutil/hwcontext_vulkan.h:199:43: warning: ‘enum AVPixelFormat’ declared inside parameter list will not be visible outside of this definition or declaration
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
|
|
|
|
|
|
| |
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
|
| |
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
| |
We want to copy the lowest amount of bytes per line, but while the buffer
stride is sanitized, the src/dst stride can be negative, and negative numbers
of bytes do not make a lot of sense.
|
|
|
|
|
| |
Some vendors (AMD) require dedicated allocation to be used for all imported
images.
|
|
|
|
|
|
| |
Otherwise, the frames context is considered to be ready to handle
mapping, and it doesn't get initialized the normal way through
.frames_init.
|
| |
|
|
|
|
| |
Speeds up both use cases by 30%.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The size of a single allocation performed by av_malloc() or av_realloc()
is supposed to be bounded by max_alloc_size, which defaults to INT_MAX
and can be set by the user; yet currently this is not completely
honoured: The actual value used is max_alloc_size - 32. How this came
to be can only be understood historically:
a) 0ecca7a49f8e254c12a3a1de048d738bfbb614c6 disallowed allocations
> INT_MAX. At that time the size parameter of av_malloc() was an
unsigned and the commentary added ("lets disallow possible ambiguous
cases") indicates that this was done as a precaution against calling the
functions with negative int values. Genuinely limiting the size of
allocations to INT_MAX doesn't seem to have been the intention given
that at this time the memalign hack introduced in commit
da9b170c6f06184a5114dc66afb8385cd0ffff83 (which when enabled increased
the size of allocations slightly so that one can return a correctly
aligned pointer that actually does not point to the beginning of the
allocated buffer) was already present.
b) Said memalign hack allocated 17 bytes more than actually desired, yet
allocating 16 bytes more is actually enough and so this was changed in
a9493601638b048c44751956d2360f215918800c; this commit also replaced
INT_MAX by INT_MAX - 16 (and made the limit therefore a limit on the size
of the allocated buffer), but kept the comment, although there is nothing
ambiguous about allocating (INT_MAX - 16)..INT_MAX.
c) 13dfce3d44f99a2d7df71aba8ae003d58db726f7 then increased 16 to 32 for
AVX, 6b4c0be5586acad3bbafd7d2dd02a8328a5ab632 replaced INT_MAX by
MAX_MALLOC_SIZE (which was of course defined to be INT_MAX) and
5a8e994287d8ef181c0a5eac537547d7059b4524 added max_alloc_size and made
it user-selectable.
d) 4fb311c804098d78e5ce5f527f9a9c37536d3a08 then dropped the memalign
hack, yet it kept the -32 (probably because the comment about ambiguous
cases was still present?), although it is no longer needed at all after
this commit. Therefore this commit removes it and uses max_alloc_size
directly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
| |
|
|
|
|
| |
Otherwise custom vulkan device contexts won't work.
|
|
|
|
| |
This allows us to speed up only-uploading or only-downloading use cases.
|
|
|
|
|
| |
They're nothing special, and there's no reason they should always use the
default flags.
|
|
|
|
|
| |
Some users may need special formats that aren't available when the STORAGE
flag bit is set, which would result in allocations failing.
|
|
|
|
|
|
|
|
| |
This was never actually used, likely due to confusion, as the device context
also had one used for uploads and downloads.
Also, since we're only using it for very quick image barriers (which are
practically free on all hardware), use the compute queue instead of the
transfer queue.
|
|
|
|
|
| |
If an external pool was provided we skipped all of frames init,
including the exec context.
|
|
|
|
|
|
| |
This commit makes full use of the enabled queues to provide asynchronous
uploads of images (downloads remain synchronous).
For a pure uploading use cases, the performance gains can be significant.
|
|
|
|
| |
Makes it easier to support multiple queues
|
|
|
|
|
| |
Some things like using ImageLists were from a really old version that
still used multiplanar images.
|
|
|
|
|
|
|
| |
With this, the puzzle of making libplacebo, ffmpeg and any other Vulkan
API users interoperable is complete.
Users of both libraries can initialize one another's contexts without having
to create a new one.
|
|
|
|
|
| |
This, along with the next patch, are the last missing pieces to being
interoperable with libplacebo.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows for users who derive devices to set options for the
new device context they derive.
The main use case of this is to allow users to enable extensions
(such as surface drawing extensions) in Vulkan while deriving from
the device their frames are on. That way, users don't need to write
any initialization code themselves, since the Vulkan spec invalidates
mixing instances, physical devices and active devices.
Apart from Vulkan, other hwcontexts ignore the opts argument since they
don't support options at all (or in VAAPI and OpenCL's case, options are
currently only used for device selection, which device_derive overrides).
|
| |
|
|
|
|
|
|
|
|
| |
This will be used for AVCodecContext->profile. By specifying constants in the
encoders we won't have to use the common AVCodecContext options table and
different encoders can use the same profile name even with different values.
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
| |
Use 0, which selects the alignment automatically.
|
|
|
|
|
|
|
|
|
| |
Enables HEVC Range Extension decoding support (Linux) for 4:2:2 8/10 bit
on ICL+ (gen11 +) platform.
Restricted to linux only for now.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
|
|
|
|
| |
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
|
|
| |
Many places are using their own custom code for handling overflow
around timestamps or other int64_t values. There are enough of these
now that having some common saturated math functions seems sound.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
|
|
| |
On windows and darwin (and modern android), the x18 register is reserved
and shouldn't be modified by user code, while it is freely available on
linux. Strictly avoid it, to keep the assembly code portable.
This would have helped catch the issue fixed in 872790b1f9be6
immediately.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
|
|
| |
Both API and CLI users can enable any extension they'd like using the options.
|
|
|
|
|
|
| |
Only warn instead. API users can find out which extensions were unavailable
by using the enabled_inst_extensions and enabled_dev_extensions fields.
This eliminates having to trial-and-error to find which extensions were missing.
|