Fixes: signed integer overflow: -532410125 + -1759642300 cannot be represented in type 'int'
Fixes: 57045/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVARC_fuzzer-637023665297817
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When including the header in decklink_enc.cpp it would be fed
through the C++ compiler rather than the C compiler, which has
more strict warnings when comparing signed/unsigned values.
Make the local variables unsigned to match the arguments they are
being passed for those functions.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
This patch will add MPEG4 encoder using Android Mediacodec
Signed-off-by: Samuel Mira <samuel.mira@qt.io<mailto:samuel.mira@qt.io>>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The only encoders avaliable using mediacodec were h264 and hevc. This
patch adds the vp9 encoder.
Signed-off-by: Samuel Mira <samuel.mira@qt.io<mailto:samuel.mira@qt.io>>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
While the inline cabac assembly has worked correctly in i386 builds
historically, modern compiler updates has started showing issues
with it, when the function gets inlined into larger contexts that
fail to provide the amount of free registers as this function
requires.
This was an issue with Clang on Windows on i386, which was fixed
in c6d284b945324a7bc70ea8b9056040c8148aa835. However, recently
the same issues also have started showing up with GCC (both for
Windows and Linux). Whether the issue appears seems dependent on
a lot of optimizer tuning (e.g. the issue appears or goes away
depenent on the combinaton of -march= and -mtune= options),
potentially due to the compiler making different decisions on
how much to inline.
Fixes: https://trac.ffmpeg.org/ticket/8903
Signed-off-by: Martin Storsjö <martin@martin.st>
Add support for writing sBIT chunks, which mark the significant
bit depth of the PNG file. This obtains the metadata using the field
bits_per_raw_sample of AVCodecContext.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Add support for reading sBIT chunks, which mark the significant
bit depth of the PNG file. This passes the metadata using the field
bits_per_raw_sample of AVCodecContext.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Some specifications require the size of ld/eld frames to be 480 samples
instead of the default 512. libfdk_aac provides an option to set an alternative
frame size, but it's not exposed via the ffmpeg interface.
This patch adds a frame_length option to solve this problem.
Signed-off-by: Raphael Schlarb <info@raphael.schlarb.one>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: James Almer <jamrial@gmail.com>
This patch add another ARIB caption decoder using libaribcaption
external library.
Unlike libaribb24, it supports 3 types of subtitle outputs:
* text: plain text
* ass: ASS formatted text
* bitmap: bitmap image
Default subtitle type is ass as same as libaribb24.
Advantages compared with libaribb24 on ASS subtitle are:
* Subtitle positioning.
* Multi-rect subtitle: some captions are displayed at different
position at a time.
* More stability and reproducibility.
To compile with this feature:
* libaribcaption external library has to be pre-installed.
https://github.com/xqq/libaribcaption
* configure with `--enable-libaribcaption` option.
`--enable-libaribb24` and `--enable-libaribcaption` options are
not exclusive. If both enabled, libaribcaption precedes as
order listed in `libavcodec/allcodecs.c`.
Signed-off-by: rcombs <rcombs@rcombs.me>
To support bitmap subtitle output, remove AV_CODEC_PROP_TEXT_SUB
property from codec descriptor for AV_CODEC_ID_ARIB_CAPTION.
This is similar to `libavcodec/libzvbi-teletextdec.c`
(AV_CODEC_ID_DVB_TELETEXT).
Instead, each subtitle decoder has to specify a subtitile format.
`libavcodec/libaribb24.c` uses same AV_CODEC_ID_ARIB_CAPTION and
expects AV_CODEC_PROP_TEXT_SUB to be set, so this adds a line to
specify a format there.
Signed-off-by: rcombs <rcombs@rcombs.me>
This change on its own is almost certainly not correct; however, in
testing, many samples show notable improvement.
Signed-off-by: J. Dekker <jdek@itanimul.li>
This reverts commit 9413bdc381.
That commit broke the fate HEVC tests - unfortunately I only
tested checkasm for that patch, and that function is still
lacking checkasm coverage.
Signed-off-by: Martin Storsjö <martin@martin.st>
pts may not be set on input packets, which could result in the entire stream
being discarded.
This reverts commit 8fc2dedfe6, reintroducing the
behavior it replaced but now allowing the caller to manually drop the preroll
samples by looking at the skip_samples side data at the start while ignoring it
on seek, by setting the skip_manual avctx flag.
Fixes ticket #10251.
Suggested-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>
These fields are supposed to store information about the packet the
frame was decoded from, specifically the byte offset it was stored at
and its size.
However,
- the fields are highly ad-hoc - there is no strong reason why
specifically those (and not any other) packet properties should have a
dedicated field in AVFrame; unlike e.g. the timestamps, there is no
fundamental link between coded packet offset/size and decoded frames
- they only make sense for frames produced by decoding demuxed packets,
and even then it is not always the case that the encoded data was
stored in the file as a contiguous sequence of bytes (in order for pos
to be well-defined)
- pkt_pos was added without much explanation, apparently to allow
passthrough of this information through lavfi in order to handle byte
seeking in ffplay. That is now implemented using arbitrary user data
passthrough in AVFrame.opaque_ref.
- several filters use pkt_pos as a variable available to user-supplied
expressions, but there seems to be no established motivation for using them.
- pkt_size was added for use in ffprobe, but that too is now handled
without using this field. Additonally, the values of this field
produced by libavcodec are flawed, as described in the previous
ffprobe conversion commit.
In summary - these fields are ill-defined and insufficiently motivated,
so deprecate them.
The AVPacket given to an encoder's encode callback
is unreferenced generically on error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AVPacket given to an encoder's encode callback
is unreferenced generically on error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AVPacket given to an encoder's encode callback
is unreferenced generically on error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
FFmpeg's assembly code currently does not abide by the
plattform-specific ABIs wrt its handling of the X86 MMX flag:
Resetting the MMX state is deferred to avoid doing it multiple times
instead of ensuring that the CPU is in floating point state
upon return from any function.
Furthermore, resetting said state is sometimes done generically,
namely for all the decoders using the ordinary decode callback;
yet this is not done for the decoders using the receive_frame API.
This led to problems when MJPEG (and the MJPEG-based decoders)
were switched to the receive_frame API in commit
e9a2a87773, because ff_mjpeg_decode_sos()
only resets the MMX state on success, not on failure.
Such issues are probably still possible with SMVJPEG, which still
uses the receive_frame API. See issue #10210.
This commit therefore also resets the MMX state for
the receive_frame API to avoid any more surprises of this sort.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The base_enable_flag is parallel to three_Spline_enable_flag. The
typesetting of the specification is very misleading.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
It conflicts the comments. The operation based on Delta_enable_mode
can be applied by user during tone mapping.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This also fixes the number of planes for the NV formats
(this seems to not have caused any problems).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
