As the second argument for init_get_bits(avctx and buf) can be crafted,
a return value check for this function call is necessary,
so replace init_get_bits with init_get_bits8 and add return value check.
Consider data as invalid if ff_wma_run_level_decode
gets out with an error.
It avoids an unpleasant sound distorsion.
See http://trac.ffmpeg.org/ticket/9358
As the second argument for init_get_bits(buf) can be crafted,
a return value check for this function call is necessary.
Also replace init_get_bits with init_get_bits8.
Signed-off-by: Peter Ross <pross@xvid.org>
Do this by allocating AVBSFContext together with the data that is
currently in AVBSFInternal; or rather: Put AVBSFContext at the beginning
of a new structure called FFBSFContext (which encompasses more than just
the internal fields and is a proper context in its own right, hence the
name) and remove the AVBSFInternal altogether.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This unbreaks the fate-checkasm-hevc_pel test on arm targets.
The assembly assumed that the width passed to the DSP functions is
a multiple of 8, while the checkasm test used other widths too.
This wasn't noticed before, because the hevc_pel checkasm tests
(that were added in 9c513edb79 in
January) weren't run as part of fate until in
b492cacffd in August.
As this hasn't been an issue in practice with actual full decoding
tests, it seems like the actual decoder doesn't call these functions
with such widths. Therefore, we could alternatively fix the test
to only test things that the real decoder does, and this modification
could be reverted.
Signed-off-by: Martin Storsjö <martin@martin.st>
If slice_type is > 9, the access to ff_h264_golomb_to_pict_type is
out-of-bounds. Fix this by simply setting the slice_type to 0 in this
case.
This is completely inconsequential because the value is only being used
to being used as an offset in the calculation of the film grain seed
value, a corruption of which is practically invisible.
Fixes coverity ticket #1490802
Signed-off-by: James Almer <jamrial@gmail.com>
Some frame threaded decoders set it, but this information never reached the
caller in frame threading scenarios.
Signed-off-by: James Almer <jamrial@gmail.com>
Because we need access to ref frames without film grain applied, we have
to add an extra AVFrame to H264Picture to avoid messing with the
original. This requires some amount of overhead to make the reference
moves work out, but it allows us to benefit from frame multithreading
for film grain application "for free".
Unfortunately, this approach requires twice as much RAM to be constantly
allocated for ref frames, due to the need for an extra buffer per
H264Picture. In theory, we could get away with freeing up this memory as
soon as it's no longer needed (since ref frames do not need film grain
buffers any longer), but trying to call ff_thread_release_buffer() from
output_frame() conflicts with possible later accesses to that same frame
and I'm not sure how to synchronize that well.
Tested on all three cases of (no fg), (fg present but exported) and (fg
present and not exported), with and without threading.
Co-authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: James Almer <jamrial@gmail.com>
This could arguably also be a vf, but I decided to put it here since
decoders are technically required to apply film grain during the output
step, and I would rather want to avoid requiring users insert the
correct film grain synthesis filter on their own.
The code, while in C, is written in a way that unrolls/vectorizes fairly
well under -O3, and is reasonably cache friendly. On my CPU, a single
thread pushes about 400 FPS at 1080p.
Apart from hand-written assembly, one possible avenue of improvement
would be to change the access order to compute the grain row-by-row
rather than in 8x8 blocks. This requires some redundant PRNG calls, but
would make the algorithm more cache-oblivious.
The implementation has been written to the wording of SMPTE RDD 5-2006
as faithfully as I can manage. However, apart from passing a visual
inspection, no guarantee of correctness can be made due to the lack of
any publicly available reference implementation against which to
compare it.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: James Almer <jamrial@gmail.com>
From SMPTE RDD 5-2006, the grain seed is to be computed from the
following definition of `pic_offset`:
> When decoding H.264 | MPEG-4 AVC bitstreams, pic_offset is defined as
> follows:
> - pic_offset = PicOrderCnt(CurrPic) + (PicOrderCnt_offset << 5)
> where:
> - PicOrderCnt(CurrPic) is the picture order count of the current frame,
> which shall be derived from [the video stream].
>
> - PicOrderCnt_offset is set to idr_pic_id on IDR frames. idr_pic_id
> shall be read from the slice header of [the video stream]. On non-IDR I
> frames, PicOrderCnt_offset is set to 0. A frame shall be classified as I
> frame when all its slices are I slices, which may be optionally
> designated by setting primary_pic_type to 0 in the access delimiter NAL
> unit. Otherwise, PicOrderCnt_offset it not changed. PicOrderCnt_offset is
> updated in decoding order.
Co-authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: James Almer <jamrial@gmail.com>
this prevents some mismatches in config values for realtime and all
intra modes, avoiding failures like:
[libaom-av1 @ ...] Failed to initialize encoder: Invalid parameter
[libaom-av1 @ ...] Additional information: g_lag_in_frames out of
range [..0]
Signed-off-by: James Zern <jzern@google.com>
This is needed by the AV1-Annex B and AV1-OBU demuxers.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array read
Fixes: 36341/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-6737583085322240
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: 36331/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3_fuzzer-5140494328922112.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
transpose_4x8H was declared in vp9lpf_16bpp_neon, however this macro is
not unique to vp9 and could be used elsewhere.
Signed-off-by: Mikhail Nitenko <mnitenko@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Use an uint32_t for the NAL unit size of an AVC H.264 NAL unit instead
of an int as a left shift of a signed value is undefined behaviour
if the result doesn't fit into the target type.
Also make the log message never output negative lengths.
Fixes: left shift of 16711968 by 8 places cannot be represented in type 'int'
Fixes: 36601/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-6581933285965824
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Unlike libx264, libx265 does not have a separate "unspecified"/"auto"
default for color range, so we do always have to specify it.
Thus, we are required to handle the RGB case on the libavcodec
side to enable the correct value to be written out in in case
of RGB content with unspecified color range being received.
In other words:
1. If the user has set color range specifically, follow that.
2. If the user has not set color range specifically, set full
range by default in case of RGB and YUVJ pixel formats.
By default the x264 full range flag is set to -1. By not setting
it to something else, we can let libx264 handle the RGB case.
Additionally, change the preference order to user-specified range
first, and then any fall-back logic left for the YUVJ pix_fmts.
Fixes the capture part of #9374
Also adapt some FATE tests to already cover this.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The current code reads the wrong number of bits for `fg_model_id`, which
causes all of the values downstream of this to contain corrupt values.
Fixes: corrupt SEI values
Fixes: 4ff73add5d
Signed-off-by: Niklas Haas <git@haasn.dev>
Certain mov/mp4 files have parameter sets out of band, and when required for a
sample it may be propagated within the relevant packet's side data.
This fixes parsing said files if the SPS and/or PPS in the side data is
different than the one in extradata.
Signed-off-by: James Almer <jamrial@gmail.com>
Using ff_cbs_read() on the raw buffer will not parse it as extradata,
resulting in parsing errors for example when handling ISOBMFF avcC.
This helper works around that.
Signed-off-by: James Almer <jamrial@gmail.com>
This commit fixes the bug as report in
https://trac.ffmpeg.org/ticket/9231 by removing the line that
overwrites the user settings for max_b_frames.
Signed-off-by: Anselm Busse <anselm.busse@outlook.com>
Signed-off-by: Rick Kern <kernrj@gmail.com>
The SDK supports LowPower and non-LowPower modes, but some features are
available only under one of the two modes. Currently non-LowPower mode
is always chosen in FFmpeg if the mode is not set to LowPower
explicitly. User will experience some SDK errors if a LowPower related
feature is specified but the mode is not set to LowPower. With this
patch, the mode is set to unknown by default in FFmpeg, the SDK is able
to choose a workable mode for the specified features.
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This allows user set hw_device_ctx instead of hw_frames_ctx for QSV
decoders, hence we may remove the ad-hoc libmfx setup code from FFmpeg.
"-hwaccel_output_format format" is applied to QSV decoders after
removing the ad-hoc libmfx code. In order to keep compatibility with old
commandlines, the default format is set to AV_PIX_FMT_QSV, but this
behavior will be removed in the future. Please set "-hwaccel_output_format qsv"
explicitly if AV_PIX_FMT_QSV is expected.
The normal device stuff works for QSV decoders now, user may use
"-init_hw_device args" to initialise device and "-hwaccel_device
devicename" to select a device for QSV decoders.
"-qsv_device device" which was added for workarounding device selection
in the ad-hoc libmfx code still works
For example:
$> ffmpeg -init_hw_device qsv=qsv:hw_any,child_device=/dev/dri/card0
-hwaccel qsv -c:v h264_qsv -i input.h264 -f null -
/dev/dri/renderD128 is actually open for h264_qsv decoder in the above
command without this patch. After applying this patch, /dev/dri/card0
is used.
$> ffmpeg -init_hw_device vaapi=va:/dev/dri/card0 -init_hw_device
qsv=hw@va -hwaccel_device hw -hwaccel qsv -c:v h264_qsv -i input.h264
-f null -
device hw of type qsv is not usable in the above command without this
patch. After applying this patch, this command works as expected.
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Will remove unnecessary allocations when both src and dst picture contain
references to the same buffers.
Signed-off-by: James Almer <jamrial@gmail.com>
