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>
Avoids allocations and frees and error checks for said allocations;
also avoids a few indirections and casts.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead, use forward declarations; and in order not to affect
any user include these headers for them, but not internally.
This has the advantage of removing implicit inclusions of these
headers from almost all files providing codecs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This decoding flag makes decoders drop all frames after a parameter
change, but what exactly constitutes a parameter change is not well
defined and will typically depend on the exact use case.
This functionality then does not belong in libavcodec, but rather in
user code
The goal is to distinguish between APIs provided by the generic layer to
individual codecs and APIs internal to the generic layer.
Start by moving ff_{decode,encode}_receive_frame() and
ff_{decode,encode}_preinit() into this new header, as those functions
are called from generic code and should not be visible to individual
codecs.
Frame counters can overflow relatively easily (INT_MAX number of frames is
slightly more than 1 year for 60 fps content), so make sure we use 64 bit
values for them.
Also deprecate the old 32 bit frame_number attribute.
Signed-off-by: Marton Balint <cus@passwd.hu>
The idea behind last_pkt_props was to store the properties of the last packet
fed to the decoder. Any sort of queueing required by CODEC_CAP_DELAY decoders
that consume several packets before they start outputting frames should be done
by the decoders in question. An example of this is libdav1d.
This is required for the following commits that will fix last_pkt_props in
frame threading scenarios, as well as maintain its contents during flush.
This revers commit 022a12b306.
Signed-off-by: James Almer <jamrial@gmail.com>
This ensures that if AVCodecContext.channels or
AVCodecContext.channel_layout are set, AVCodecContext.ch_layout
has the equivalent values after this block.
(In case these values are set inconsistently, the consistency check
for ch_layout below will error out.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In particular, check the provided channel layout for encoders
without AVCodec.ch_layouts set. This fixes an infinite loop
in the WavPack encoder (and maybe other issues in other encoders
as well) in case the channel count is zero.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This block was scheduled for removal, which means that no validation would have
taken place after the old API was removed.
It was algo going to mistakenly remove an unrelated bits_per_coded_sample
check.
Signed-off-by: James Almer <jamrial@gmail.com>
At this point active_thread_type is set iff active_thread_type
is set to FF_THREAD_FRAME iff AVCodecInternal.frame_thread_encoder
is set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Handling this in general code makes more sense than handling it in
individual codec files, because it would be a lot of unnecessary code
duplication for the plenty of formats that support exporting ICC
profiles (jpg, png, tiff, webp, jxl, ...).
encode.c and decode.c will be in charge of initializing this state as
needed, so we merely need to make sure to uninit it afterwards from the
common destructor path.
Signed-off-by: Niklas Haas <git@haasn.dev>
The amount of padding samples reported by containers take into account the
extended samplerate in HE-AAC.
Fixes ticket #9671.
Signed-off-by: James Almer <jamrial@gmail.com>
and remove FF_CODEC_CAP_INIT_THREADSAFE
All our native codecs are already init-threadsafe
(only wrappers for external libraries and hwaccels
are typically not marked as init-threadsafe yet),
so it is only natural for this to also be the default state.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.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>
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>
It works, but it is not documented to work.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, codec.h contains both public and private parts
of AVCodec. This exposes the internals of AVCodec to users
and leads them into the temptation of actually using them
and forces us to forward-declare structures and types that
users can't use at all.
This commit changes this by adding a new structure FFCodec to
codec_internal.h that extends AVCodec, i.e. contains the public
AVCodec as first member; the private fields of AVCodec are moved
to this structure, leaving codec.h clean.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move FF_CODEC_TAGS_END as well as struct AVCodecDefault.
This reduces the amount of files that have to include internal.h
(which comes with quite a lot of indirect inclusions), as e.g.
most encoders don't need it. It is furthemore in preparation
for moving the private part of AVCodec out of the public codec.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids including version.h in all source files, avoiding
unnecessary rebuilds when the version number is bumped. Only
version_major.h is included by the main header, which defines
availability of e.g. FF_API_* macros, and which is bumped much
less often.
This isn't done for libavutil/version.h, because that header needs
to be included essentially everywhere due to LIBAVUTIL_VERSION_INT
being used wherever an AVClass is constructed.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since the request_channel_layout is used only by a handful of codecs,
move the option to codec private contexts.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Decoders implementing the receive_frame API currently mostly use
stack packets to temporarily hold the packet they receive from
ff_decode_get_packet(). This role directly parallels the role of
in_pkt, the spare packet used in decode_simple_internal for the
decoders implementing the traditional decoding API. Said packet
is unused by the generic code for the decoders implementing the
receive_frame API, so allow them to use it to fulfill the function
it already fulfills for the traditional API for both APIs.
There is only one caveat in this: The packet is automatically
unreferenced in avcodec_flush_buffers(). But this is actually
positive as it means the decoders don't have to do this themselves
(in case the packet is preserved between receive_frame calls).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Just check for the existence of the bsf. This is equivalent to
the old criterion of the AVCodecContext being a decoder.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is now checked by FATE that no encoder capable of flushing
uses frame threads, so this now redundant runtime check can
be removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If an AVCodec has a private class, its priv_data_size must be > 0
and at the end of a successful call to avcodec_open2()
the AVCodecContext's priv_data must exist and its first element
must be a pointer to said AVClass. This should not be conditional
on priv_data_size being > 0 (which is tested by FATE) or
on the private context having been successfully allocated
(which has to have happened at that point). So remove these
preconditions to make the test stricter.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
