So far, AV_READ_TIME would return the cycle counter. This posed two
problems:
1) On recent systems, it would just raise an illegal instruction
exception. Indeed RDCYCLE is blocked in user space to ward off some
side channel attacks. In particular, this would cause the random
number generator to crash.
2) It does not match the x86 behaviour and the apparent original intent
of AV_READ_TIME in the functional code base (outside test cases).
So this replaces the cycle counter with the time counter. The unit is
a platform-dependent constant fraction of time, and the value should be
stable across harts (RISC-V lingo for physical CPU thread).
It is currently probably not possible for it to be negative as
the needed 2Mb input buf size is not achievable. But it is more
robust to check for it too.
If it would become negative than code like
s->samples[0][n] = s->samples[0][s->nb_samples + n];
would crash
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: shift exponent 1285 is too large for 32-bit type 'int'
Fixes: 60870/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVARC_fuzzer-5332050340347904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -1403461578 + -843974775 cannot be represented in type 'int'
Fixes: 60868/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1VIDEO_fuzzer-4599793035378688
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The fate-run.sh shell script exports LC_ALL=C before invoking the
test executables; this is probably done for consistency.
When executing Windows binaries with Wine, it normally handles
UTF-8 command line parameters just fine - but with LC_ALL set to
C, it treats them as plain ASCII.
As the unicode command line parameters wasn't the main thing
being tested here, just convert them to plain ASCII, for
portability. This fixes the test for all test configurations that
use Wine.
Signed-off-by: Martin Storsjö <martin@martin.st>
ddc1cd5cdd defined WIN32_LEAN_AND_MEAN
globally, which makes for much fewer transitive includes from
windows.h. With that define, CoTaskMemFree no longer gets
implicitly declared by just including windows.h, but one has to
include the right header objbase.h too.
That commit caused ole32 to no longer get detected, which caused
dxva2 to no longer be enabled. This gets fixed by this patch.
Signed-off-by: Martin Storsjö <martin@martin.st>
This commit fixes bug #10495
The code had several bugs related to post-loop compensation code:
- test assembly instruction performs bitwise AND operation and
generate flags used by jz branch instruction. Wrong test condition
leads to incorrect branching
- Incorrect compensation code for some branches
Signed-off-by: Evgeny Pavlov <lucenticus@gmail.com>
Currently, create_pnext is only used if an applicable external memory
extension is enabled. This will usually the case when used from the command
line, but may not be when the Vulkan context is created manually.
For images used in video decoding, create_pnext contains the video profile
list, which is mandatory.[1] This fixes a GPU crash when using RADV.
[1] https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkImageCreateInfo.html#VUID-VkImageCreateInfo-usage-04815
Signed-off-by: Chris Spencer <spencercw@gmail.com>
This abstraction is similar to the existing one for pthread_mutex_t and
pthread_once_t functions, and should reduce the amount of ifdeffery used
in future code.
Signed-off-by: James Almer <jamrial@gmail.com>
C++ doesn't support designated initializers until C++20. We have
a bunch of pre-defined channel layouts, the gains to make them
usable in C++ exceed the losses.
Bump minor version so C++ project can check before use these defines.
Also initialize .opaque field explicitly to reduce warning in C++.
Signed-off-by: James Almer <jamrial@gmail.com>
if !ph_deblocking_params_present_flag is true, ph_deblocking_filter_disabled_flag infered from pps
if !sh_deblocking_params_present_flag is true, sh_deblocking_filter_disabled_flag infered from ph
Failed clips:
ENT444MAINTIER_C_Sony_3.bit
ENT444HIGHTIER_D_Sony_3.bit
Signed-off-by: James Almer <jamrial@gmail.com>
if pps_alf_info_in_ph_flag is true
sh_alf_enabled_flag infered from ph
Failed clip:
LTRP_A_ERICSSON_3.bit
Signed-off-by: James Almer <jamrial@gmail.com>
if sh_picture_header_in_slice_header_flag is true
sh_lmcs_used_flag and sh_explicit_scaling_list_used_flag are infered from ph
Failed clips:
LMCS: CLM_A_KDDI_2.bit STILL444_A_KDDI_1.bit
Scaling: SCALING_B_InterDigital_1.bit SCALING_A_InterDigital_1.bit
Signed-off-by: James Almer <jamrial@gmail.com>
By default the OpenEXR decoder outputs linear light pixel data by
applying a gamma=1.0 transfer (i.e. a no-op). When it does so, it
should tag the data as linear so color-managed filters or other tools
can work with it correctly.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
If user doesn't set framerate when he creates a filter, the filter uses
default framerate {0, 1}. This causes error when setting timebase to
1/framerate. Now change it to pass inlink->time_base to outlink when
framerate is not set.
This patch fixes ticket: #10476#10468
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Including winsock2.h or windows.h without WIN32_LEAN_AND_MEAN cause
bzlib.h to parse as nonsense, due to an instance of #define char small
in rpcndr.h.
See:
https://stackoverflow.com/a/27794577
Signed-off-by: L. E. Segovia <amy@amyspark.me>
Signed-off-by: Martin Storsjö <martin@martin.st>
because the flv specification said the video frametype
should use value range from 0x00 to 0x70,
so use 0xF0 have no problem before support enhanced flv,
but the 0xF0 will get incorrect result after support enhanced flv,
so should set the video frametype mask 0x70 to make it correct now.
Reported-By: flvAnalyser <hybase@qq.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
