Much like XV30 and XV36 in d75c4693fe,
XV48 is added to support 16bit 4:4:4 as defined by Microsoft.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes: use of uninitialized variable
Fixes: 368729566/clusterfuzz-testcase-minimized-ffmpeg_dem_MPEGTS_fuzzer-6044501804646400
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: Paul B Mahol <onemda@gmail.com>
Fixes: signed integer overflow: 4611686016549392399 + 9223372033098784800 cannot be represented in type 'long long'
Fixes: 368503277/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5928227458056192
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: Paul B Mahol <onemda@gmail.com>
Fixes: Integer overflow
Fixes: 368725672/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-5009093023563776
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: Paul B Mahol <onemda@gmail.com>
Fixes: out of array access
Fixes: 368143798/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-6475823425585152
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: Paul B Mahol <onemda@gmail.com>
Film grain support adds a huge amount of overhead to the H264Context
structure for a feature that is rarely used. On low end devices or
pages that have lots of media this bloats memory usage rapidly.
This changes the static film grain metadata allocations to be dynamic
which reduces the H264Context size from 851808 bytes to 53444 bytes.
Bug: https://crbug.com/359358875
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This fixes corner cases (requires version 4 or a spec update)
Fixes: Ticket5548
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
And preserve the public SwsContext as separate name. The motivation here
is that I want to turn SwsContext into a public struct, while keeping the
internal implementation hidden. Additionally, I also want to be able to
use multiple internal implementations, e.g. for GPU devices.
This commit does not include any functional changes. For the most part, it is
a simple rename. The only complications arise from the public facing API
functions, which preserve their current type (and hence require an additional
unwrapping step internally), and the checkasm test framework, which directly
accesses SwsInternal.
For consistency, the affected functions that need to maintain a distionction
have generally been changed to refer to the SwsContext as *sws, and the
SwsInternal as *c.
In an upcoming commit, I will provide a backing definition for the public
SwsContext, and update `sws_internal()` to dereference the internal struct
instead of merely casting it.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-disposition:
Clarify the meaning of the default value, and how the '+' and '-'
prefixes work. Add more examples.
-stats:
Clarify that it appears as an "info"-level log.
-progress:
Add info about the "progress" key's value being "continue" or "end".
Add an example of logging to stdout.
Signed-off-by: Soma Lucz <luczsoma@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Forgotten after fd8b0dcfed61ddf36b9523aa4ba1badc493b7707.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
I want to pull options out of SwsInternal, so we need to make this field
a dedicated int that gets updated as appropriate in ff_swscale().
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Exactly what it says on the tin.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Replacing the old sws_isSupported* API with a more consistent family
of functions that follows the same signature and naming convention,
including a placeholder for testing the color space parameters that
we don't currently implement conversions for.
These functions also perform some extra basic sanity checking.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Groups together all relevant color metadata from an AVFrame. While we could
use AVFrame directly, keeping it a separate struct has three advantages:
1. Functions accepting an SwsFormat will definitely not care about the
data pointers.
2. It clearly separates sanitized and raw metadata, since the function to
construct an SwsFormat from an AVFrame will also sanitize.
3. It's slightly more lightweight to pass around.
Move these into a new header file "utils.h" to avoid crowding
swscale_internal.h even more, and also to solve a circular dependency issue
down the line.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Merely a convenience wrapper around sws_freeContext(). The name change is for
parity with the other sws_* functions.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
I want to start grouping "legacy" functions which I tend to deprecate
together, away from the new ones.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Slightly more convenient, especially for the upcoming refactor which will
turn SwsContext into a public struct.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The issue is that if dedicated allocation is used, VkBufferCreateInfo.size
and the actual allocated size mismatched, which is a validation error.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
