H.264 and H.265 levels' names are usually of the form "x" or "x.y"
with x and y being single digits; the one exception are the H.264 1b
levels. All of those levels' names fit into a char[4] and it is likely
that this future levels will do so, too.
Therefore this commit changes the H26(4|5)LevelDescriptor structures
to use such a char [4] instead of a pointer to a const char. This makes
the structures smaller (when sizeof(char*) == 8) and avoids relocations,
thereby moving the corresponding arrays from .data.rel.ro into .rodata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They were done in preparation for an upcoming 1.0 release.
Keep supporting previous releases for the time being.
Reviewed-by: BBB
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: Timeout
Fixes: 36875/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PICTOR_fuzzer-4842960888922112
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Tested-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ff_pnm_parser and ff_vp3_parser already hit the current limit;
an addition to the former (to handle pfm) is planned.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Unlike libx264, libx265 does not handle the chroma format check
on its own side, so in order to not write out values which are
supposed to be ignored according to the specification, we limit
the writing out of chroma sample location to 4:2:0 only.
Fixes invalid reports of bad lossless crc.
While here make end of stream message into debug level as it is
not really important to user.
Also wait for new major sync frame as invalid concating of files
may produce invalid files, which cause various errors.
This results in warnings on compilers which don't support it,
objections were raised during the review process about it but went unnoticed,
and the speed benefit is highly compiler and version specific, and
also not very critical.
We generally hand-write assembly to optimize loops like that, rather
than use compiler magic, and for 40% best case scenario, it's simply
not worth it.
Plus, tree vectorization is still problematic with GCC and disabled by default
for a good reason, so enabling it locally is sketchy.
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 9c513edb7999a35ddcc6e3a8d984a96c8fb492a3 in
January) weren't run as part of fate until in
b492cacffd36ad4cb251ba1f13ac398318ee639a 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>
