Intra Block Copy relies on reconstructed pixels from the current frame.
We skip IBC during the inter prediction stage and handle it during the reconstruction stage.
An Intra Block Copy clip may use different modes for luma and chroma.
For example, MODE_IBC for luma and MODE_INTRA for chroma.
We have to check luma and chroma CuPredMode (cpm) separately.
AV_CODEC_CAP_VARIABLE_FRAME_SIZE has been set for alac_at encoder,
which means avctx->frame_size should be zero. However, alac_at
encoder also set avctx->frame_size. This leading to assert failure
in ffmpeg_sched.c
av_assert0(enc->sq_idx[0] >= 0);
Actually, the implementation of audiotoolboxenc.c doesn't support
frame_size been zero.
Fix#10720.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Using av_bprint_init_for_buffer() avoids copying data
into the internal AVBPrint buffer (or worse: to allocate
a temporary buffer in case the internal buffer does not
suffice).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using av_bprint_init_for_buffer() avoids copying data
into the internal AVBPrint buffer (or worse: to allocate
a temporary buffer in case the internal buffer does not
suffice).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using av_bprint_init_for_buffer() avoids copying data
into the internal AVBPrint buffer (or worse: to allocate
a temporary buffer in case the internal buffer does not
suffice). It also ensures that the data is always
0-terminated.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using av_bprint_init_for_buffer() avoids copying data
into the internal AVBPrint buffer (or worse: to allocate
a temporary buffer in case the internal buffer does not
suffice). It also ensures that the data is always
0-terminated, whereas the current code never does this
and returns success in case the length of the
string to write and the size of the buffer coincide.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is undefined behaviour (see C11, 6.10.3 (4); see also
14dd0a9057019e97ff9438f6cc1502f6922acb85).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This callback is optional and should therefore only be set
if it actually does something.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Inside a function an extra ';' is a null statement;
but outside of it it simply must not happen.
So remove them.
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These arrays are currently accessed via uint16_t* pointers
although nothing guarantees their alignment. Furthermore,
this is problematic wrt the effective-type rules.
Fix this by using a union of arrays of uint8_t and uint16_t.
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
max_bin_idx can be at most LMCS_MAX_BIN_SIZE - 1 here,
so pivot[LCMS_MAX_BIN_SIZE + 1] may be accessed,
but pivot has only LCMS_MAX_BIN_SIZE + 1 elements
(unless the values of pivot were so that it is always
assured that pivot[LCMS_MAX_BIN_SIZE] is always < sample
(which it is iff it is always < 2^bit_depth - 1)).
So reorder the checks.
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It used to be used with preallocated packet buffers with
the old encode API, but said API is no more and therefore
there is no reason for this to be public any more.
So deprecate it and use an internal replacement
for the encoders using it as an upper bound for the
size of their headers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
Forgotten in 50a8cbb23e9a982292bf7737004c97eba776c00e and
a51279bbdea0d6db920d71980262bccd0ce78226.
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>
