The call to ff_exp2fi() here always uses arguments in the normal
range, so that the branches in ff_exp2fi() are unnecessary.
This is so because JPEG2000 itself only supports up to
128 bits per component per pixel (we only support far less);
furthermore, expn is always 0..31 for the decoder and also
sane for the encoder, so that the difference between these
two values is always in the normal range of -126..128.
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It allows the compiler to combine two reads and writes of adjacent
32bit memory locations into 64bit read-writes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use ff_avg_pixels16_mmxext or ff_avg_pixels16_sse2
(for users with SSE2_FAST) instead.
This also allows to remove ff_avg_pixels16_mmx,
as this was its last remaining user.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This together with adjusting the inclusion define allows for the
build to not fail with latest Vulkan-Headers that contain the
stabilized Vulkan AV1 decoding definitions.
Compilation fails currently as the AV1 header is getting included
via hwcontext_vulkan.h -> <vulkan/vulkan.h> -> vulkan_core.h, which
finally includes vk_video/vulkan_video_codec_av1std.h and the decode
header, leading to the bundled header to never defining anything
due to the inclusion define being the same.
This fix is imperfect, as it leads to additional re-definition
warnings for things such as
VK_STD_VULKAN_VIDEO_CODEC_AV1_DECODE_SPEC_VERSION. , but it is
not clear how to otherwise have the bundled version trump the
actually standardized one for a short-term compilation fix.
According to ITU-T H.265 7.4.2.1 this byte sequence should not appear in a
NAL unit but in practice in rare cases it seems it does, possibly due to buggy
encoders. Other players like VLC and Quicktime seem to be fine with it.
Currently when this sequence is found it is treated as if the next start code
has been found and the NAL unit gets truncated.
This change limits the code to only look for first start code 0x0000001 or
first escape 0x000003.
Sadly i can't share the original source file with the issue but the first
80 bytes of the NAL unit looks like this:
│00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f│0123456789abcdef│
0x00000│00 00 00 01 02 01 d0 bc 57 a1 b8 44 70 01 00 0b│........W..Dp...│
0x00010│80 2e 00 c2 6c ec 3e b9 e3 03 fb 91 2e d2 43 cb│....l.>.......C.│
0x00020│1d 2c 00 00 02 00 02 00 5c 93 72 6f 31 76 18 00│.,......\.ro1v..│
0x00030│08 38 aa b1 4c 33 3f fd 08 cb 77 9b d4 3c db 02│.8..L3?...w..<..│
0x00040│a2 04 73 15 75 de 3b c4 67 c0 8f ca ad 31 f1 99│..s.u.;.g....1..│
Signed-off-by: Anton Khirnov <anton@khirnov.net>
I generated a DXV2 file with an interesting alpha channel using
Adobe Media Encoder 2015 and compared decoding it using Resolume Alley
and ffmpeg. Similarly to DXV3 files, Alley expects premultiplied alpha
and ffmpeg matches its decoding more closely when it does the same.
Reference file: https://connorworley.com/dxv2-dxt5.mov
Existing FATE tests for DXV2 files do not cover this change.
Signed-off-by: Connor Worley <connorbworley@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This change decouples the frame dimensions from avctx, which is useful
for DXV decoding, and fixes incorrect behavior in the existing
implementation.
Tested with `make fate THREADS=7` and
`make fate THREADS=7 THREAD_TYPE=slice`.
Signed-off-by: Connor Worley <connorbworley@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
We currently mostly do not empty the MMX state in our MMX
DSP functions; instead we only do so before code that might
be using x87 code. This is a violation of the System V i386 ABI
(and maybe of other ABIs, too):
"The CPU shall be in x87 mode upon entry to a function. Therefore,
every function that uses the MMX registers is required to issue an
emms or femms instruction after using MMX registers, before returning
or calling another function." (See 2.2.1 in [1])
This patch does not intend to change all these functions to abide
by the ABI; it only does so for ff_simple_idct_mmx, as this
function can by called by external users, because it is exported
via the avdct API. Without this, the following fragment will
assert (on x86_32, as ff_simple_idct_mmx is not used on x64):
int16_t __attribute__ ((aligned (16))) block[64];
AVDCT *dct = avcodec_dct_alloc();
dct->idct_algo = FF_IDCT_AUTO;
avcodec_dct_init(dct);
dct->idct(block);
av_assert0_fpu();
[1]: https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/intel386-psABI-1.1.pdf
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The PPS should be used instead of the SPS to get the current picture's
dimensions. Using the SPS can cause issues if the resolution changes
mid-sequence. In particular, it was leading to invalid memory accesses
if the resolution decreased.
Patch replaces sps->{width,height} with pps->{width,height}. It also
removes sps->{width,height}, as these are no longer used anywhere.
Fixes crash when decoding DVB V&V test sequence
VVC_HDR_UHDTV1_ClosedGOP_Max3840x2160_50fps_HLG10_res_change_without_RPR
Signed-off-by: Frank Plowman <post@frankplowman.com>
This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx.
Co-authored-by: Erik Språng <sprang@webrtc.org>
Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com>
Signed-off-by: James Zern <jzern@google.com>
Makes it robust against adding fields before it, which will be useful in
following commits.
Majority of the patch generated by the following Coccinelle script:
@@
typedef AVOption;
identifier arr_name;
initializer list il;
initializer list[8] il1;
expression tail;
@@
AVOption arr_name[] = { il, { il1,
- tail
+ .unit = tail
}, ... };
with some manual changes, as the script:
* has trouble with options defined inside macros
* sometimes does not handle options under an #else branch
* sometimes swallows whitespace
fc->ref points to an old VVCFrame, which cannot be used after frame_context_setup.
This prevents crashes in decode_nal_units-->ff_vvc_report_frame_finished.
Signed-off-by: Frank Plowman <post@frankplowman.com>
The avctx passed to avcodec_string() may have unset coded dimensions, as is the
case when called by av_dump_format() where the streams had all the needed
information at the container level, and as such no frames were decoded
internally.
Signed-off-by: James Almer <jamrial@gmail.com>
Besides simplifying address computations (it saves 432B of .text
in hevcdsp.o alone here) it also fixes undefined behaviour that
occurs if mx or my are 0 (happens when the filters are unused)
because they lead to an array index of -1 in the old code.
This happens in the checkasm-hevc_pel FATE-test.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
fbw_channels must be > 0 as teh code is only run if cpl_enabled is set and that requires mode >= AC3_CHMODE_STEREO
CID 718138 Uninitialized scalar variable
assumes this assert to be false
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For a corrupted stream, the value of nalu_len read from the extradata is not reliable.
We need to perform additional checks
Fixes: fuzzer timeout
Fixes: 65253/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_MP4TOANNEXB_fuzzer-4972412487467008
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These chunks contain the Content Light Level Information and the
Mastering Display Color Volume information that FFmpeg already supports
as AVFrameSideData. This patch adds support for the png encoder to save
this metadata as the corresponding chunks in the PNG stream.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
These chunks contain the Content Light Level Information and the
Mastering Display Color Volume information that FFmpeg already supports
as AVFrameSideData. This patch adds support for the png decoder to read
these chunks if present and attach the corresponding side data to the
decoded frame.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
The function signature for bytestream2_seek is (gb, offset, whence);
Before this patch, the code passed (gb, SEEK_SET, offset), which is
incorrect.
Siged-off-by: Leo Izen <leo.izen@gmail.com>
vc1_hwaccel_pixfmt_list_420 is referenced even if
!(CONFIG_WMV3IMAGE_DECODER || CONFIG_VC1IMAGE_DECODER) so move it out
of the #if block.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The new API requires an extra array member at the very end,
which old API users did not do.
This disables in-place RDFT transforms and instead
does the transform out of place by copying once, there shouldn't
be a significant loss of speed as our in-place FFT requires a reorder
which is likely more expensive in the majority of cases to do.
These inline implementations of AV_COPY64, AV_SWAP64 and AV_ZERO64
are known to clobber the FPU state - which has to be restored
with the 'emms' instruction afterwards.
This was known and signaled with the FF_COPY_SWAP_ZERO_USES_MMX
define, which calling code seems to have been supposed to check,
in order to call emms_c() after using them. See
0b1972d409,
29c4c0886d and
df215e5758 for history on earlier
fixes in the same area.
However, new code can use these AV_*64() macros without knowing
about the need to call emms_c().
Just get rid of these dangerous inline assembly snippets; this
doesn't make any difference for 64 bit architectures anyway.
Signed-off-by: Martin Storsjö <martin@martin.st>
The previous assumption that DXV needs to be aligned to 16x16 was
erroneous. 4x4 works just as well, and FATE decoder tests pass for all
texture formats.
On the encoder side, we should reject input that isn't 4x4 aligned,
like the HAP encoder does, and stop aligning to 16x16. This both solves
the uninitialized reads causing current FATE tests to fail and produces
smaller encoded outputs.
With regard to correctness, I've checked the decoding path by encoding a
real-world sample with git master, and decoding it with
ffmpeg -i dxt1-master.mov -c:v rawvideo -f framecrc -
The results are exactly the same between master and this patch.
On the encoding side, I've encoded a real-world sample with both master
and this patch, and decoded both versions with
ffmpeg -i dxt1-{master,patch}.mov -c:v rawvideo -f framecrc -
Under this patch, results for both inputs are exactly the same.
In other words, the extra padding gained by 16x16 alignment over 4x4
alignment has no impact on decoded video.
Signed-off-by: Connor Worley <connorbworley@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Andreas Rheinhardt
Jan Ekström
Mattias Wadman
Connor Worley
James Almer
sunyuechi
Frank Plowman
Dariusz Marcinkiewicz
Anton Khirnov
Nuo Mi
Kieran Kunhya
Michael Niedermayer
Leo Izen
Akihiko Odaki
Lynne
Martin Storsjö