| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
nvenc_h264
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
|
|
| |
nvenc_hevc
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
| |
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
| |
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
|
|
|
|
| |
Fixes: signed integer overflow: -193177 * 11585 cannot be represented in type 'int'
Fixes: 20557/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP9_fuzzer-5704852816789504
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: 21390/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-6242539519868928
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
|
| |
negative
Fixes: left shift of negative value -8321365
Fixes: 20506/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-4798062906310656
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: -16 * 134217879 cannot be represented in type 'int'
Fixes: 20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DST_fuzzer-5639509530378240
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
| |
Fixes ticket #8649.
Reported-by: irc user Xogium
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old approach used some highly complex delta computation math and
output-delaying.
I do not remember what the initial reasoning behind that was, but given
that we can just offset the dts by the amount of bframes, it seems wholy
unnecessary.
This leaves open an issue with VFR content, for which some more complex
logic might be needed.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
|
|
|
|
|
|
|
|
|
| |
Due to a typo, it was impossible to write 0.595 / -4.5 dB
of ltrt_cmixlev, ltrt_surmixlev, loro_cmixlev, loro_surmixlev.
Without any error 0.841 / -1.5 dB was written to file.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
Rav1e currently uses the time base given to it only for ratecontrol... where
the inverse is taken and used as a framerate. So, do what we do in other wrappers
and use the framerate if we can.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
|
|
|
|
| |
Fixes ticket #7303
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
|
|
|
|
| |
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
|
|
| |
We only care about the right most bit.
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
v4l2_m2m uses device memory mapped buffers to store dequeued
frames/packets (reference counted by AVBufferRef). When the reference
count drops to zero, the buffer ownership is returned back to the
device, so that they can re-filled with frames/packets.
There are some cases when all the capture buffers are in userspace
(i.e. due to internal buffering in ffmpeg). On the s5p-mfc this causes
an infinite wait when polling to dequeue the buffers, which can be
prevented by increasing the total number of buffers. This commit adds a
warning when all the capture buffers are dequeued.
Reviewed-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
The data of an AVPacket may be a part of the data of an AVBufferRef;
Therefore av_grow_packet() doesn't reallocate if the available space in
the actual buffer is sufficient for the enlargement. But given that it
also zeroes the padding it also needs to make sure that the buffer is
actually writable; this commit implements this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enqueue/dequeue of the capture buffers should continue while draining.
Reference: linux/Documentation/media/uapi/v4l/dev-decoder.rst
"The client must continue to handle both queues independently,
similarly to normal decode operation. This includes:
...
- queuing and dequeuing CAPTURE buffers, until a buffer marked with
the V4L2_BUF_FLAG_LAST flag is dequeued"
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
|
|
|
|
|
|
|
|
| |
line
Found-by: 黄宁 <tsukimurarin@163.com>
Reviewed-by: Nick Renieris <velocityra@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
|
| |
The DNG code hardcodes plane 0 at some places, so its better to disallow cases
that have more planes.
Fixes: eg_crash
Found-by: 黄宁 <tsukimurarin@163.com>
Reviewed-by: Nick Renieris <velocityra@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
| |
This is less confusing
Reviewed-by: Nick Renieris <velocityra@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
|
|
|
| |
dng spec 1.5.0.0
"BitsPerSample
Supported values are from 8 to 32 bits/sample. The depth must be the same for each sample if
SamplesPerPixel is not equal to 1."
Fixes: eg_crash
Found-by: 黄宁 <tsukimurarin@163.com>
Reviewed-by: Nick Renieris <velocityra@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
Fixes: Timeout (21sec -> 80ms)
Fixes: 20673/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TXD_fuzzer-5177453863763968
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
Fixes: Timeout (21sec -> 255ms)
Fixes: 20709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SVQ1_fuzzer-5085075089915904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"slice mode" option seems to be unnecessary since it could be
determined by -slices/max_nal_size.
default: SM_FIXEDSLCNUM_SLICE mode with cpu-number slices.
-slices N: SM_FIXEDSLCNUM_SLICE mode with N slices.
-max_nal_size: SM_SIZELIMITED_SLICE mode with limited size slices.
Add FF_API_OPENH264_SLICE_MODE macro to remove this option after
LIBAVCODEC_VERSION_MAJOR = 59.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
|
| |
Libopenh264enc would set the slice according to the number of cpu cores
if uiSliceNum equals to 0 (auto) in SM_FIXEDSLCNUM_SLICE mode.
Prompt a warning for user to catch this.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RC_BITRATE_MODE:
set BITS_EXCEEDED to iCurrentBitsLevel and allows QP adjust
in RcCalculatePictureQp().
RC_BUFFERBASED_MODE:
use buffer status to adjust the video quality.
RC_TIMESTAMP_MODE:
bit rate control based on timestamp, introduced in release 1.4.
Default to use RC_QUALITY_MODE.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It would be 200kbps bitrate with gop size = 12 by default
which generated too many IDR frames in rather low bit rate.
The quality would be poor.
Set these default values to -1 to check whether it's specified
by user explicitly.
Use 2Mbps bitrate as nvenc sugguested, and leave gop size
untouched in libopenh264.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clip iMinQp/iMaxQp to (1, 51) for user specified qp range.
If not set, leave iMinQp/iMaxQp untouched and use the values (0, 51)
initialized in FillDefault(), and the QP range would be adjusted to the
defaults inside libopenh264 library according to the iUsageType, (12, 42)
for iUsageType == CAMERA_VIDEO_REAL_TIME which is default.
<https://github.com/cisco/openh264/blob/master/codec/encoder/core/src/encoder_ext.cpp#L375>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation allows passing levels to libavcodec as
integers (such as "31" instead of "3.1").
However, in this case, the maximum reference frame value per level was
ignored because libavcodec converted the string to 310 instead of 31.
Since libx264 has correctly parsed the level to int
(x4->params.i_level_idc), we should rely on this value instead of
attempting to parse the level string on our own.
Signed-off-by: Josh Brewster <josh.brewster@protonmail.com>
Signed-off-by: Josh de Kock <josh@itanimul.li>
|
|
|
|
|
|
|
|
| |
Without this setting, bitrate and qmin/qmax options have no
effect on the s5p-mfc hardware encoder.
Reviewed-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
|
|
|
|
|
|
|
|
|
| |
Currently the user gets unhelpful warnings when some default parameters
are not supported by the device. The verbosity of these log messages has
been changed to AV_LOG_DEBUG.
Reviewed-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
|
|
|
|
| |
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
|
|
|
|
| |
These encoders all accept VAAPI surfaces in a hardware frames context.
|
|
|
|
|
|
| |
All of these encoders can accept libmfx surfaces directly in a hardware
frames context, or they can accept software frames if a suitable device
is supplied to use.
|
| |
|
|
|
|
|
| |
This already applied to decoders as well as hwaccels, and adding encoder
support was going to make the name even more inaccurate.
|
|
|
|
|
|
|
|
|
|
| |
inter_ref_pic_set_prediction_flag is set
Fixes: out of array access
Fixes: 20446/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5707770718584832
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
Fixes: Timeout (105sec -> 1sec)
Fixes: 20479/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-5769846937878528
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 1073741824 by 1 places cannot be represented in type 'int32_t' (aka 'int')
Fixes: 21245/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5683334274613248
Change to int16_t suggested by Lynne
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
| |
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
|
|
|
|
|
| |
Signed-off-by: Peter Ross <pross@xvid.org>
Reviewed-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
| |
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
|
| |
libavutil/mem.h is unneeded since 33d18982fa03feb061c8f744a4f0a9175c1f63ab,
the commit that introduced the new packet-based bsf API, because with
this switch the allocations were no longer performed directly, but by
av_new_packet().
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With 33d18982fa03feb061c8f744a4f0a9175c1f63ab, the commit introducing
the new packet-based bsf API, a new buffer was no longer allocated
directly, but via av_new_packet(), so that libavutil/mem.h was no longer
needed.
Moreover since commit dc99ee6b08e54de13b4c82ff265609b6ab83e3d8
av_packet_make_writable() is employed which copies the data in case it
is unavoidable so that string.h is no longer used (it was used for
memcpy()).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
Since 33d18982fa03feb061c8f744a4f0a9175c1f63ab (the commit that
introduced the new bsf API) allocating an enlarged buffer in case
extradata needs to be added to a packet is done via av_new_packet(),
so that libavutil/mem.h is no longer needed.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
|
|
|
|
|
|
| |
This bsf never needed libavutil/mem.h.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
|
|
|
|
|
|
| |
This bsf never needed internal.h.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
|
|
|
|
|
|
|
|
| |
This bsf doesn't have any options, so including libavutil/opt.h is
unnecessary.
Reviewed-by: Peter Ross <pross@xvid.org>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation of av_dict_set() states that values >= 0 indicate
success, whereas av_packet_unpack_dictionary() implies that return
values > 0 are impossible. So only forward the return value of
av_dict_set() in av_packet_unpack_dictionary() on error.
(Btw: av_dict_set() does currently not return values > 0.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
|