Before commit f025b8e110,
every frame-threaded decoder used ThreadFrames, even when
they did not have any inter-frame dependencies at all.
In order to distinguish those decoders that need the AVBuffer
for progress communication from those that do not (to avoid
the allocation for the latter), the former decoders were marked
with the FF_CODEC_CAP_ALLOCATE_PROGRESS internal codec cap.
Yet distinguishing these two can be done in a more natural way:
Don't use ThreadFrames when not needed and split ff_thread_get_buffer()
into a core function that calls the user's get_buffer2 callback
and a wrapper around it that also allocates the progress AVBuffer.
This has been done in 02220b88fc
and since that commit the ALLOCATE_PROGRESS cap was nearly redundant.
The only exception was WebP and VP8. WebP can contain VP8
and uses the VP8 decoder directly (i.e. they share the same
AVCodecContext). Both decoders are frame-threaded and VP8
has inter-frame dependencies (in general, not in valid WebP)
and therefore the ALLOCATE_PROGRESS cap. In order to avoid
allocating progress in case of a frame-threaded WebP decoder
the cap and the check for the cap has been kept in place.
Yet now the VP8 decoder has been switched to use ProgressFrames
and therefore there is just no reason any more for this check
and the cap. This commit therefore removes both.
Also change the value of FF_CODEC_CAP_USES_PROGRESSFRAMES
to leave no gaps.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVCodec.pix_fmts is only intended for encoders (decoders use
the get_format callback to let the user choose a pix fmt).
So remove them for the decoders for which this is possible
without further complications; keep them for now in the codecs
that actually use them (by passing avctx->codec->pix_fmts to
ff_get_formatt()).
Also notice that some of these lists were wrong; e.g.
317b7b06fd added support for YUV444P16
for cuviddec, but forgot to add it to pix_fmts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Of all these VLCs here, only VLC.table was really used
after init, so use the ff_vlc_init_tables API
to get rid of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Therefore use a proper prefix for this API, e.g.
ff_init_vlc_sparse -> ff_vlc_init_sparse
ff_free_vlc -> ff_vlc_free
INIT_VLC_LE -> VLC_INIT_LE
INIT_VLC_USE_NEW_STATIC -> VLC_INIT_USE_STATIC
(The ancient INIT_VLC_USE_STATIC has been removed
in 595324e143, so that
the NEW has been dropped.)
Finally, reorder the flags and change their values
accordingly.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It reduces typing: Before this patch, there were 11 callbacks
that exceeded the 80 char line length limit; now there are zero.
It also allows to remove ONLY_IF_THREADS_ENABLED() in
libavutil/internal.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It reduces typing: Before this patch, there were 105 codecs
whose long_name-definition exceeded the 80 char line length
limit. Now there are only nine of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.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>
In C, qualifiers for arrays are broken:
const VLC_TYPE (*foo)[2] is a pointer to an array of two const VLC_TYPE
elements and unfortunately this is not compatible with a pointer
to a const array of two VLC_TYPE, because the latter does not exist
as array types are never qualified (the qualifier applies to the base
type instead). This is the reason why get_vlc2() doesn't accept
a const VLC table despite not modifying the table at all, as
there is no automatic conversion from VLC_TYPE (*)[2] to
const VLC_TYPE (*)[2].
Fix this by using a structure VLCElem for the VLC table.
This also has the advantage of making it clear which
element is which.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible, because every given FFCodec has to implement
exactly one of these. Doing so decreases sizeof(FFCodec) and
therefore decreases the size of the binary.
Notice that in case of position-independent code the decrease
is in .data.rel.ro, so that this translates to decreased
memory consumption.
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>
Given that the AVCodec.next pointer has now been removed, most of the
AVCodecs are not modified at all any more and can therefore be made
const (as this patch does); the only exceptions are the very few codecs
for external libraries that have a init_static_data callback.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Besides removing code duplication the method for determining the offset
of each VLC table in the VLC_TYPE buffer also has the advantage of not
wasting space for skipped AIC mode 1 VLCs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
RealVideo 4.0 has a VLC that encodes two intra types per code; each
intra type is in the range 0..8 (inclusive) and up until now the VLC
used symbols in the range 0..80; one type was encoded as the remainder
when dividing the symbol by 9 whereas the other type was encoded as
symbol / 9. This is suboptimal; a better way would be to use the high
and low nibble to encode each symbol. But an even better way is to use
16bit symbols so that the two intra types can be directly written as
a 16bit value.
This commit implements this; in order to avoid huge tables the symbols
are stored as uint8_t with high and low nibbles encoding one type each;
they are only unpacked to uint16_t during initialization.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After permuting the codes, symbols and lengths tables used to initialize
the VLC so that the codes are ordered from left to right in the Huffman
tree, the codes become redundant as they can be easily computed from the
lengths at runtime; in this case one has to use explicit symbol tables,
but all the symbols used here fit into an uint8_t, whereas some codes
needed uint16_t. This saves about 1.6KB.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The current design, where
- proper init is called for the first per-thread context
- first thread's private data is copied into private data for all the
other threads
- a "fixup" function is called for all the other threads to e.g.
allocate dynamically allocated data
is very fragile and hard to follow, so it is abandoned. Instead, the
same init function is used to init each per-thread context. Where
necessary, AVCodecInternal.is_copy can be used to differentiate between
the first thread and the other ones (e.g. for decoding the extradata
just once).
The most interesting parts are initialization in ff_MPV_common_init() and
uninitialization in ff_MPV_common_end().
ff_mpeg_unref_picture and ff_thread_release_buffer have additional NULL
checks for Picture.f, because these functions can be called on
uninitialized or partially initialized Pictures.
NULL pointer checks are added to ff_thread_release_buffer() stub function.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Also break some long lines, remove codec function placeholder comments
and add spaces in sample/pixel format lists.
Signed-off-by: Martin Storsjö <martin@martin.st>
Statistics for bourne.rmvb -an -f null
1 thread: 37.12s user 0.03s system 99% cpu 37.174 total
2 threads: 47.63s user 0.24s system 185% cpu 25.807 total
4 threads: 41.21s user 0.30s system 327% cpu 12.674 total
FF_COMMON_FRAME holds the contents of the AVFrame structure and is also copied
to struct Picture. Replace by an embedded AVFrame structure in struct Picture.
Andreas Rheinhardt
Andreas Rheinhardt
Anton Khirnov
Michael Niedermayer
Diego Biurrun
Vittorio Giovara
Himangi Saraogi
wm4
Martin Storsjö
Michael Niedermayer
Carl Eugen Hoyos
Christophe Gisquet
Janne Grunau
Mans Rullgard
Kostya Shishkov