Add a parameter to libaom-av1 encoder to enforce some of the single
image constraints in the AV1 encoder. Setting this flag will limit
the encoder to producing exactly one frame and the sequence header
that is produced by the encoder will be conformant to the AVIF
specification [1].
Part of Fixing Trac ticket #7621
[1] https://aomediacodec.github.io/av1-avif
Signed-off-by:: Vignesh Venkatasubramanian <vigneshv@google.com>
The general decoding API uses bitstream filters and an AVFifo
and therefore AVCodecInternal contains pointers to an AVBSFContext
and to an AVFifo and lavc/internal.h includes lavc/bsf.h and
lavu/fifo.h.
Yet actually, only two files are supposed to use these, namely
avcodec.c and (mainly) decode.c. For all the other files,
it should be an opaque type that they should not touch and that
they need not know anything about. This can be achieved by not
including these headers and using the structs instead of the
corresponding typedefs.
This also forces translation units that really use the BSF
and the FIFO APIs themselves to include the relevant headers
directly instead of relying on indirect inclusions (up until now,
even avcodec.c and decode.c relied on fifo.h to be included
by internal.h).
Of course, it also avoids unnecessary rebuilds when bsf.h or fifo.h
change.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Left shifts of signed types are UB unless the results fit
into the type. (Furthermore the value to be shifted need to be
nonnegative.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Several encoders (roqvideo, svq1, snow, and the mpegvideo family)
currently call ff_get_buffer(). However this function is written
assuming it is called by a decoder. Though nothing has been obviously
broken by this until now, that may change in the future.
To avoid potential future issues, introduce a simple encode-specific
wrapper around avcodec_default_get_buffer2() and enforce its use in
encoders.
Required to remux m2ts to mkv
Minor changes and porting to FFBitStreamFilter done by the committer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids having to rebuild big files every time FFMPEG_VERSION
changes (which it does with every commit).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This way values such as maxrate/bufsize can be utilized further
down the chain.
First, syncs up the max_rate and buffer_size from SVT-AV1 back to
avctx, and then in case at least one of the utilized values is
nonzero, adds the CPB properties side data.
This way we can filter out the default value for this member, which
is nonzero. Bases on the current affairs that bit rate based rate
control is nonzero in SVT-AV1.
This removes a dependency of checkasm on lavc/v210_enc.o
and also allows to inline ff_v210enc_init() irrespectively of
interposing.
This dependency pulled basically all of libavcodec into checkasm,
in particular all codecs.
This also makes checkasm work when using shared Windows builds:
On Windows, it needs to be known to the compiler whether a data
symbol is external to the library/executable or not; hence the
need for av_export_avutil. checkasm needs access to the internals
of the libraries it tests and is therefore linked statically to all
the libraries. This means that the users of avpriv_cga_font and
avpriv_vga16_font in libavcodec (namely ansi.o, bintext.o, tmv.o)
end up in the same executable as the symbols, although they have
been compiled as if these symbols were external, leading to linker
errors. With this commit said files are discarded by the linker,
bypassing this problem.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This removes a dependency of checkasm on lavc/v210_dec.o
and also allows to inline ff_v210dec_init() irrespectively of
interposing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add options to h264, hevc and prores encoders to prioritize speed.
Speeds up encoding by 50% - 70%
Signed-off-by: Simone Karin Lehmann <simone@lisanet.de>
Signed-off-by: Rick Kern <kernrj@gmail.com>
Issue: On extremely new hardware using either IceLake or super sets of
Intel IceLakes avx512 instructions, commit
d4cd8830bdac3e26c8e75cd92e574c159fecc4f7 causes build issues.
Specifically a NASM macro expansion of qpel_filter_v is never properly
defined/initialized.
The issue is the definition was erroneously placed inside a conditional
which will not trigger unless the original definition failed (has to do
with if PIC is defined, becomes a bit of a catch 22)
Specifically the error is
X86ASM libavcodec/x86/hevc_mc.o
libavcodec/x86/hevc_mc.asm:1854: error: symbol `..@88472.table' not defined
libavcodec/x86/hevc_mc.asm:1806: ... from macro
`HEVC_PUT_HEVC_QPEL_HV_AVX512ICL' defined here
libavcodec/x86/hevc_mc.asm:1730: ... from macro `QPEL_FILTER_V' defined here
...
repeats a few times...
...
make: *** [ffbuild/common.mak💯 libavcodec/x86/hevc_mc.o] Error 1
```
Specific error was discussed by kurosu and myself (fclc) on the
ffmpeg-devel irc.
This commit fixes the above by swapping lines 1796 and 1795, moving the
define out of the conditional
Side note: It seems fate didn't pick up on this, may merit looking into
(as mentioned by nevcairiel).
Reviewed-by: Wu Jianhua <toqsxw@outlook.com>
Signed-off-by: Felix LeClair (FCLC) <felix.leclair123@hotmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
This decoder uses ff_get_buffer() and does nothing weird
(it does not even rely on any alignment of the frame's data/linesize).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both AV_PIX_FMT_GRAY8 and AV_PIX_FMT_GRAY16 use unsigned values,
not signed ones. The fact that the input might be signed
in some cases in the original format doesn't change this.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The PGX decoder accesses the lines via code like
(PIXEL*)frame->data[0] + i*frame->linesize[0]/sizeof(PIXEL)
where PIXEL is a macro parameter. This code has issues with negative
linesizes, because the type of sizeof(PIXEL) is size_t, so
that on common systems i*linesize/sizeof(PIXEL) will
always be an unsigned type that is very large in case linesize is
negative. This happens to work*, but it is undefined behaviour
and e.g. leads to "src/libavcodec/pgxdec.c:114:1: runtime error:
addition of unsigned offset to 0x7efe9c2b7040 overflowed to 0x7efe9c2b6040"
errors from UBSAN.
Fix this by using (PIXEL*)(frame->data[0] + i*frame->linesize[0]).
This is allowed because linesize has to be suitably aligned.
*: Converting a negative int to size_t works by adding SIZE_MAX + 1
to the number, so that the result is off by (SIZE_MAX + 1) /
sizeof(PIXEL). Converting the pointer arithmetic (performed on PIXELs)
back to ordinary pointers is tantamount to multiplying by sizeof(PIXEL),
so that the result is off by SIZE_MAX + 1; but SIZE_MAX + 1 == 0
for the underlying pointers.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These checks were (most likely) added to check for overreads
as the bytestream2_get_* functions return 0 in this case.
Yet this is not necessary anymore as we now have an explicit check
for the size. Should the input contain a real \0, pgx_get_number()
will error out lateron.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We have already checked that there is data to be read.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Each of the three calls to pgx_get_number() consumes at least two bytes.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This patch fixes a wrong type of BTI landing pad when branching to
functions instantiated via the fft*_neon macro.
Although the previously employed paciasp instruction serves as a landing
pad, for the ways that this function is invoked it is the wrong type, resulting
in an unexpected termination of the running process.
Signed-off-by: André Kempe <andre.kempe@arm.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
match the behavior of SvtAv1EncApp to ensure pic_type is always set
before passing it to the library.
The other options for pic_type aren't currently used inside the library,
so they aren't introduced in this patch.
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Monterey needs mBytesPerFrame and mBytesPerPacket to be set, and I'm
surprised this didn't break any previous system versions.
Fixes bug #9564: Cannot decode xHE-AAC with audiotoolbox (aac_at) on
Mac OS Monterey. Fixes likely bug that none of the AudioToolbox
decoders work on Monterey.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
The size of the ICC chunk has already been accounted for when
the packet's buffer was initially set in ff_mpv_encode_picture()
and the header (including the ICC chunk) has already been written
at this point.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is a remnant of the old way for user-supplied buffers;
it is always-true since 93016f5d1d280f9cb7856883af287fa66affc04c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If one encodes MJPEG with a single slice and uses input with
AV_FRAME_DATA_ICC_PROFILE side data, the current allocation code
in ff_mpv_encode_picture() will always increase the size of the
temporary buffer used for allocating packets by the size needed
for to write the ICC chunk even when the current buffer is actually
large enough. This commit fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MJPEG is the only mpegvideo-based encoder making use of it.
Fixes linking failures in case mpegvideo_enc.c is compiled
with AMV, LJPEG and MJPEG encoders disabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
