The specifications are very vague about who has ownership, and in this case,
Vulkan takes ownership of all DMABUF FDs passed to it, causing errors
to occur if someone gave us images for mapping which were meant to be kept.
The old behavior worked with one-way VAAPI and DMABUF imports, but was broken
with clients like wlroots' dmabuf-capture.
There was a recent change in Intel's driver that triggered a driver-internal
error if the semaphore given to the command buffer wasn't initialized.
Given that the specifications require the semaphore to be initialized,
this is within spec. Unlike what's causing it in the first place, which is
that there are no ways to extract/import dma sync objects from DMABUFs,
so we must leave our semaphores bare.
The Y channel is handled by dnn, and also resized by dnn. The UV channels
are resized with swscale.
The command to use espcn.pb (see vf_sr) looks like:
./ffmpeg -i 480p.jpg -vf format=yuv420p,dnn_processing=dnn_backend=tensorflow:model=espcn.pb:input=x:output=y -y tmp.espcn.jpg
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Reviewed-by: Pedro Arthur <bygrandao@gmail.com>
Only the Y channel is handled by dnn, the UV channels are copied
without changes.
The command to use srcnn.pb (see vf_sr) looks like:
./ffmpeg -i 480p.jpg -vf format=yuv420p,scale=w=iw*2:h=ih*2,dnn_processing=dnn_backend=tensorflow:model=srcnn.pb:input=x:output=y -y srcnn.jpg
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Reviewed-by: Pedro Arthur <bygrandao@gmail.com>
This patch fixes Bug #8469
If x264 baseline profile is used with other profiles,
start_pts will be initialized to audio stream's first pts,
while the duration is calculated based on video stream's pts.
In this patch the start_pts is initialized with the correct stream's first pts.
Signed-off-by: Hongcheng Zhong <sj.hc_Zhong@sjtu.edu.cn>
Reviewed-by: Steven Liu <liuqi05@kuaishou.com>
Fixes: out of array access
Fixes: 19734/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5673507031875584
Fixes: 19353/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5703944462663680
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of negative value -1
Fixes: 20859/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ADPCM_PSX_fuzzer-5720391507247104
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of negative value -695
Fixes: 19232/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1VIDEO_fuzzer-5702856963522560
Fixes: 19555/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1VIDEO_fuzzer-5741218147598336
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add support for WavPack DSD files to the existing WavPack decoder using
avcodec/dsd to perform the 8:1 decimation to 32-bit float samples. We must
serialize the dsd2pcm operation (cross-boundary filtering) but would like
to use frame-level multithreading for the CPU-intensive DSD decompression,
and this is accomplished with ff_thread_report/await_progress(). Because
the dsd2pcm operation is independent across channels we use slice-based
multithreading for that part.
Also a few things were removed from the existing WavPack decoder that
weren't being used (primarily the SavedContext stuff) and the WavPack
demuxer was enhanced to correctly determine the sampling rate of DSD
files (and of course to no longer reject them).
Signed-off-by: David Bryant <david@wavpack.com>
Also remove the ancient reference to libmpcodecs while at it.
Signed-off-by: James Almer <jamrial@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Slices that end after their header (meaning slices after the header
without any data before the rbsp_stop_one_bit or possibly without any
rbsp_stop_one_bit at all) are invalid and are now dropped. This ensures
that one doesn't run into two asserts in cbs_h2645_write_slice_data().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: 19629/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_METADATA_fuzzer-5676822528524288
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Trailing zeroes are already discarded when splitting a fragment, which
makes the code to remove them when decomposing slices dead code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now, v4l2_m2m would write via snprintf() into an intermediate
buffer and then copy from there (via strncpy()) to the end buffer. This
commit changes this by removing the intermediate buffer.
The call to strncpy() was actually of the form strncpy(dst, src,
strlen(src) + 1) which is unsafe in general, but safe in this instance
because dst and src were both of the same size and src was a proper
zero-terminated string. But this nevertheless led to a compiler warning
"‘strncpy’ specified bound depends on the length of the source argument
[-Wstringop-overflow=]" in GCC 9.2. strlen() was unnecessary anyway.
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
If 'write_colr' movflag is set, then movflag 'prefer_icc' can
be used to first look for an AV_PKT_DATA_ICC_PROFILE entry to
encode.
If ICC profile doesn't exist, default behaviour enabled by
'write_colr' occurs.
Signed-off-by: vectronic <hello.vectronic@gmail.com>
Use desc->log2_chroma_w/h to calculate the sps->conf_win_right/bottom_offset.
Based on Table 6-1, SubWidthC and SubHeightC depend on chroma format(log2_chroma_w/h).
Based on D-28 and D-29, set the correct cropped width/height.
croppedWidth = pic_width_in_luma_samples −
SubWidthC * ( conf_win_right_offset + conf_win_left_offset );
croppedHeight = pic_height_in_luma_samples −
SubHeightC * ( conf_win_bottom_offset + conf_win_top_offset );
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Supports connecting to a RabbitMQ broker via AMQP version 0-9-1.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
3469cfab added a check for whether the extradata coincided with the
beginning of the packet's data in order not to add extradata to packets
that already have it. But the check used was buggy for packets whose
size is smaller than the extradata's size. This commit fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Mainly reindentation, but some variables were also put into a smaller
scope.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
1. Left shifts of signed values are undefined as soon as the result is
no longer representable in the target type. Therefore make nal_size
an uint32_t and drop the check for whether it is < 0.
2. The two checks for overreads (whether the length field is contained
in the packet and whether the actual unit is contained in the packet)
can be combined into one because the packet is padded, i.e. a potential
overread caused by reading the length field without checking whether
said length field is actually part of the packet's buffer is allowed
as one always stays within the padding. But one has to be aware of
a pitfall: The comparison must be performed in (at least) int64_t as
otherwise buf_end - buf might be promoted to uint32_t in which case
an already occured overread would appear as a very large number.
A comment explaining this has been added, too.
3. Units of size zero are now silently dropped; the earlier code would
instead read the first byte of the next length field (or the first byte
of padding) to infer the type of the current unit.
4. Futhermore, the earlier code returned the wrong error code. This has
been fixed, too.
Fixes#8290.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now, h264_mp4toannexb would grow the output packet's buffer by
the desired amount every time another NAL unit of the input packet has
been read; this commit changes this: The input buffer is now essentially
parsed twice, once to determine the final size of the output packet and
once to write the output packet's data.
Fixes: Timeout
Fixes: 19322/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_MP4TOANNEXB_fuzzer-5688407821123584
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
