opencl_vaapi_intel_media doesn't depend on libmfx, OpenCL™ Drivers
and Runtimes for Intel® Architectureis is a standalone release, more
information can be found in the link:
https://software.intel.com/en-us/articles/opencl-drivers.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
It is possible for there to be multiple encryption init info structure.
For example, to support multiple key systems or in key rotation. This
changes the AVEncryptionInitInfo struct to be a linked list so there
can be multiple structs without breaking ABI.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: 8521/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5639024952737792
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some of these enums have gaps in between their values, since they correspond
to the values in various specs, instead of being an incrementing list.
Fixes segfaults when, for example, using the valid API call:
av_color_primaries_from_name("jecdec-p22");
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This fix a build error on Windows:
C2440: connot convert from 'void (__cdecl *) (...)' to 'void (__stdcall *)(...)'.
Signed-off-by: Ruiling Song <ruiling.song@intel.com>
This uses any devices it can find on the host system - on a system with no
hardware device support or in builds with no support included it will do
nothing and pass.
Every fourcc in vaapi_drm_format_map should be in
vaapi_format_map, so add an assert to ensure we have the right maps.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Temporarily keep the old method for ffmpeg_filters.c choose_pix_fmt and
avfiltergraph.c pick_format() until a paletted pixel format without alpha is
introduced.
Signed-off-by: Marton Balint <cus@passwd.hu>
- Parse schm atom to get different encryption schemes.
- Allow senc atom to appear in track fragments.
- Allow 16-byte IVs.
- Allow constant IVs (specified in tenc).
- Allow only tenc to specify encryption (i.e. no senc/saiz/saio).
- Use sample descriptor to detect clear fragments.
This doesn't support:
- Different sample descriptor holding different encryption info.
- Only first sample descriptor can be encrypted.
- Encrypted sample groups (i.e. seig).
- Non-'cenc' encryption scheme when using -decryption_key.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Remove the wincrypt API calls since we don't support XP anymore and bcrypt is
available since Vista, even on Windows Store builds.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
PSEUDOPAL pixel formats are not paletted, but carried a palette with the
intention of allowing code to treat unpaletted formats as paletted. The
palette simply mapped the byte values to the resulting RGB values,
making it some sort of LUT for RGB conversion.
It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,
GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
formats. The last one, GRAY8, is more common, but its treatment is
grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
from typical Y video planes was not mapped to the correct RGB values.
This cannot be fixed, because AVFrame.color_range can be freely changed
at runtime, and there is nothing to ensure the pseudo palette is
updated.
Also, nothing actually used the PSEUDOPAL palette data, except xwdenc
(trivially changed in the previous commit). All other code had to treat
it as a special case, just to ignore or to propagate palette data.
In conclusion, this was just a very strange old mechnaism that has no
real justification to exist anymore (although it may have been nice and
useful in the past). Now it's an artifact that makes the API harder to
use: API users who allocate their own pixel data have to be aware that
they need to allocate the palette, or FFmpeg will crash on them in
_some_ situations. On top of this, there was no API to allocate the
pseuo palette outside of av_frame_get_buffer().
This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also makes
the pseudo palette optional. Nothing accesses it anymore, though if it's
set, it's propagated. It's still allocated and initialized for
compatibility with API users that rely on this feature. But new API
users do not need to allocate it. This was an explicit goal of this
patch.
Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.
Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
functions manually changed to not allocating a palette.
* commit '3a7b4ae62c798edbd82bcd8fef863c74ed2acd4a':
arm: Produce .const_data instead of .section .rodata for Mach-O
Merged-by: James Almer <jamrial@gmail.com>
This is the same combination of .section directives as used in
aarch64/asm.S.
Since Xcode 9.3, the bundled clang supports altmacro and doesn't
require using gas-preprocessor any longer.
Signed-off-by: Martin Storsjö <martin@martin.st>
This crash was introduced by 8bbf2dacbf,
which could incorrectly overwrite the failure result from creating the
device.
Fixes ticket #7108.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
