fd_dup is unused when fd and pipe have been disabled. This also
fix build error with wasi since 'dup' isn't available.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
For a frame comes from AV_HWDEVICE_TYPE_VIDEOTOOLBOX, it's
CVPixelBufferRef is maintained by a pool. CVPixelBufferRef returned
to the pool when frame buffer reference reached to zero. However,
VTCompressionSessionEncodeFrame also hold a reference to the
CVPixelBufferRef. So a new frame get from av_hwframe_get_buffer
may access a CVPixelBufferRef which still used by the encoder.
It's only after vtenc_output_callback that we can make sure
CVPixelBufferRef has been released by the encoder.
The issue can be tested with sample from trac #10884.
ffmpeg -hwaccel videotoolbox \
-hwaccel_output_format videotoolbox_vld \
-i input.mp4 \
-c:v hevc_videotoolbox \
-profile:v main \
-b:v 3M \
-vf scale_vt=w=iw/2:h=ih/2:color_matrix=bt709:color_primaries=bt709:color_transfer=bt709 \
-c:a copy \
-tag:v hvc1 \
output.mp4
Withtout the patch, there are some out of order images in output.mp4.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
ExtraSEI is used as the sourceFrameRefcon of VTCompressionSessionEncodeFrame.
It cannot hold other information which is necessary to fix another issue
in the following patch.
This patch also fixed leak of ExtraSEI on the error path of
vtenc_output_callback.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
I've accidentally used API not available on the checked version.
Additionally check for the SDK to be new enough to even have the
CVImageBufferCreateColorSpaceFromAttachments API to not fail
the build.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The VPS referenced by the SPS must always be present as the max value for
sps_max_sub_layers_minus1 is vps_max_sub_layers_minus1. This replaces a buggy
custom range check for the aforementioned field.
Also, add the missing conformance check for sps_temporal_id_nesting_flag while
at it.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: out of array access
Fixes: 69098/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG2VIDEO_fuzzer-6107989688778752
Fixes: 69599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-4848626296225792.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: CID1437470 Out-of-bounds read (out of bounds read would only occur with a pixel format of more than 4 planes)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The pointer is used before the check
Fixes: CID1591884 Dereference before null check
Sponsored-by: Sovereign Tech Fund
Reviewed-by: Roger Pack <rogerdpack@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Maybe Fixes: CID1598557 Explicit null dereferenced
Sponsored-by: Sovereign Tech Fund
Reviewed-by: Roger Pack <rogerdpack@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: CID1591931 Explicit null dereferenced
Sponsored-by: Sovereign Tech Fund
Reviewed-by: Roger Pack <rogerdpack@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: CID1598550 Resource leak
Sponsored-by: Sovereign Tech Fund
Reviewed-by: Roger Pack <rogerdpack@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: CID1591929 Copy into fixed size buffer
Sponsored-by: Sovereign Tech Fund
Reviewed-by: Roger Pack <rogerdpack@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This simplification assumes that the code is correct
Fixes: CID1560036 Logically dead code
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
