Unlike the 8-bit version, we need two iterations to process this within
128-bit vectors. This adds some extra complexity for pointer arithmetic
and counting down which is unnecessary in the 8-bit variant.
Accordingly the gain relative to C are just slight better than half as
good with 128-bit vectors as with 256-bit ones.
T-Head C908 (2 iterations):
h264_idct8_add_9bpp_c: 17.5
h264_idct8_add_9bpp_rvv_i32: 10.0
h264_idct8_add_10bpp_c: 17.5
h264_idct8_add_10bpp_rvv_i32: 9.7
h264_idct8_add_12bpp_c: 17.7
h264_idct8_add_12bpp_rvv_i32: 9.7
h264_idct8_add_14bpp_c: 17.7
h264_idct8_add_14bpp_rvv_i32: 9.7
SpacemiT X60 (single iteration):
h264_idct8_add_9bpp_c: 15.2
h264_idct8_add_9bpp_rvv_i32: 5.0
h264_idct8_add_10bpp_c: 15.2
h264_idct8_add_10bpp_rvv_i32: 5.0
h264_idct8_add_12bpp_c: 14.7
h264_idct8_add_12bpp_rvv_i32: 5.0
h264_idct8_add_14bpp_c: 14.7
h264_idct8_add_14bpp_rvv_i32: 4.7
There's nothing stopping users from writing to such buffers.
Its more accurate to say they are singular, i.e. not duplicated
between multiple submissions.
This can be helpful for global statistics, or error propagation
purposes.
This count gets incremented after init succeeds, when it should be
incremented after *alloc* succeeds. Otherwise, we leak the context on
failure.
There are no negative consequences of incrementing for
allocated-but-not-initialized contexts, as the only functions that
reference it will, in the worst case, simply behave as if called on
allocated-but-not-initialized contexts, which is in line with expected
behavior when sws_init_context() fails.
When piping ffmpeg into ffplay both programs write a status line in
the terminal. That causes flickering and invisibility of one or the
other status line.
As compromise set ffplay log level to warning, so it doesn't show
the status line.
The user is usually testing ffmpeg command lines and want's a
preview of the result. This way the user can see the ffmpeg output
and still see errors and warnings from ffplay, should they occur.
Additionally set PTS to zero in ffplay to lessen the delay until
the frames are displayed. Without it delay is quite observable
when e.g. live capturing with low frame rates.
When -trim option is used (by default), padding cells
at the beginning of the title are supposed to be ignored.
The current implementation does the ignoring after we
have locked on to the PGC navigation event stream,
but does not set the PGC/PG state properly.
This causes false positives and errors on some discs
due to a search for a program stream cell that
never succeeds. User would have to know to disable
the -trim option to work around the issue.
Simplify the logic and move it to the NAV packet
event handling, in turn implementing the behaviour
correctly and fixing the trim function for impacted discs.
Signed-off-by: Marth64 <marth64@proxyid.net>
Remove initializing ret = 0, in areas where ret is
only used to hold an error value, immediately returned,
and the function would otherwise return a literal 0.
Signed-off-by: Marth64 <marth64@proxyid.net>
Some discs (usually same ones with padding cells), also have empty
padding PTTs / chapters to accompany them. This results, for example,
in an extra chapter marker that starts and ends at 0 (no duration).
Don't add these empty chapter markers.
Signed-off-by: Marth64 <marth64@proxyid.net>
Fixes: signed integer overflow: 865309950 * 256 cannot be represented in type 'int'
Fixes: 69191/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6310214413385728
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found by reviewing code related to CID1604365 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is more a style fix than a bugfix (CID1604392 Overflowed constant)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found while reviewing CID1608712 Explicit null dereferenced
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found by code review related to CID1604563 Overflowed return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found while reviewing code related to CID1604409 Overflowed return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found by code review related to CID1604386 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found through code review related to CID1604493 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of negative value -208
Fixes: 69073/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PRORES_KS_fuzzer-4745020002336768
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found while reviewing: CID1494441 Untrusted value as argument
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is not entirely clear what would prevent such overflow so even if it is
not possible, it is better to use 64bit
Fixes: CID1491898 Unintentional integer overflow
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Otherwise, slice index will never update for hwaccel decode, and slice
RPL will be always overlap into first one which use slice index to construct.
Fixes hwaccel decoding after 47d34ba7fb
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Slice address tab only been updated in software decode slice data.
Fixes hwaccel decoding after d725c737fe.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Should make strict compilers happy.
Also, make AV_COPY128 use integer operations while at it. Removing the
inclusion of immintrin.h ensures a lot less intrinsic related headers are
included as well, which fixes a clash of defines with some Clang versions.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: James Almer <jamrial@gmail.com>
It's meant to override any codec specific (but still container level)
information, but its position is not guaranteed, so apply the values after the
entire trak structure has been parsed.
Also, replace the ugly roundabout int -> double -> int method to set SAR from
existing dimensions while at it.
Signed-off-by: James Almer <jamrial@gmail.com>
