avcodec/rv10: Reduce the size of the tables used to initialize VLCs
This can be achieved by switching to ff_init_vlc_from_lengths() which
allows to replace two uint16_t tables for codes with uint8_t tables for
the symbols by permuting the tables so that the codes are ordered from
left to right in the tree in which case they can be easily computed from
the lengths at runtime.
And after doing so, it became apparent that the tables for the symbols
are actually the same for luma and chroma, so that one can even omit one
of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/cook: Avoid big length tables for VLC initialization
Permuting the tables used to initialize the Cook VLCs so that the code
tables are ordered from left to right in the tree revealed that the
length of the codes are ascending from left to right. Therefore one can
run-length encode them to avoid the big length tables; this saves a bit
more than 1KB.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/cook: Make tables to initialize VLCs smaller
Up until now, the Cook decoder used tables for the lengths of codes and
tables of the codes itself to initialize VLCs; the tables for the codes
were of type uint16_t because the codes were so long. It did not use
explicit symbol tables. This commit instead reorders the tables so that
the code tables are sorted from left to right in the tree. Then the
codes can be easily derived from the lengths and therefore be omitted.
This comes at the price of explicitly coding the symbols, but this is
nevertheless a net win because most of the symbols tables can be coded
on one byte. Furthermore, Cook actually does not use a contiguous range
of symbols for its main VLC tables and the old code compensated for that
by adding holes (codes of length zero) to the tables (that are skipped by
ff_init_vlc_sparse()). This is no longer necessary with the new
approach. All in all, this saves about 1.7KB.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/wnv1: Make array for initializing VLC smaller
This is possible by switching to ff_init_vlc_from_lengths() which allows
to replace the table for the codes (which need an uint16_t) by a table
of symbols which fit into an uint8_t. Also switch to an ordinary
INIT_VLC macro while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/clearvideo: Improve handling of VLC escape values
Both the motion vector as well as the bias VLCs have an escape code;
for the motion vectors, this value depended on the specific VLC table,
whereas all the bias VLCs used the same value; the escape value has not
been inlined in the latter case.
But for both kinds of VLCs there are lots of values that are unused for
all the VLCs of each kind and each of these can be used as common escape
value, thus allowing to inline the escape value. This commit implements
this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After the motion vector and bias values tables have been reordered so
that the codes are ordered from left to right, it emerged that the
length of these entries are actually ascending for every table.
Therefore it is possible to encode them in a run-length style and create
the actual length tables during runtime. This commit implements this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/clearvideo: Avoid code tables for initializing VLCs
The ClearVideo decoder uses VLC tables that are initialized at runtime
from static length, symbol and codes tables. Yet the code tables can be
omitted by subjecting all of these tables to the permutation that orders
the codes from left to right in the tree. After this is done, the codes
can be easily computed at runtime from the lengths and therefore
omitted. This saves about 10KB.
Only one minor complication is encountered when doing so: The tree
corresponding to the AC VLC codes is incomplete; but this can be
handled by adding an entry with negative length.
Furthermore, there are also VLCs that are only initialized with lengths
and codes tables with codes of type uint16_t. These have also been
switched to ff_init_vlc_from_lengths() as this means that one can
replace the uint16_t codes tables with uint8_t symbols tables.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The IMC decoder uses Huffman tables which are created at runtime from
length tables of type uint8_t and code tables of type uint16_t together
with an implicit symbols table (i.e. symbol[i] == i). This commit
changes this: All three tables are subjected to the same permutation to
order the codes from left to right in the tree; afterwards the codes can
be omitted because they are easily computable at runtime from the
lengths, whereas the symbols need to be explicitly coded now. But said
symbols fit into an uint8_t, so one saves space.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The On2 audio decoder uses huge tables to initialize VLC tables. These
tables (mostly) use symbols tables in addition to the codes tables and
the lengths tables. This commit makes the codes tables redundant and
removes them: If all tables are permuted so that the codes are ordered
from left to right in the Huffman tree, the codes become redundant and
can be easily calculated at runtime from the lengths
(via ff_init_vlc_from_lengths()); this also avoids sorting the codes in
ff_init_vlc_sparse()*.
The symbols tables are always 16bit, the codes tables are 32bit, 16bit
or (rarely) 8bit, the lengths tables are always 8bit. Even though some
symbols tables have been used twice (which is no longer possible now
because different permutations need to be performed on the code tables
sharing the same symbol table in order to order them from left to right),
this nevertheless saves about 28KB.
*: If the initializations of the VLCs are repeated 2048 times
(interleaved with calls to free the VLCs which have not been timed), the
number of decicycles spent on each round of initializations improves
from 27669656 to 7356159.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Smacker Huffman tables are already stored in a tree-like structure;
in particular, they are naturally ordered from left to right in the
tree and are therefore suitable to be initialized by
ff_init_vlc_from_lengths() which avoids traversing the data twice in
order to sort only the codes that are so long that they need into a
subtable.
This improves performance (and reduces codesize): For the sample from
ticket #2425 the number of decicycles for parsing and creating the VLCs
in smka_decode_frame() decreased from 412322 to 359152 (tested with
10 runs each looping 20 times over the file).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
One can offload the computation of the codes to
ff_init_vlc_from_lengths(); this also improves performance: The number
of decicycles for one call to read_code_table() decreased from 198343
to 148338 with the sample sample-cllc-rgb.avi from the FATE suite; it
has been looped 100 times and the test repeated ten times to test it
sufficiently often.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/bitstream: Allow static VLC tables to be bigger than needed
Right now the allocated size of the VLC table of a static VLC has to
exactly match the size actually used for the VLC: If it is not enough,
abort is called; if it is more than enough, an error message is
emitted. This is no problem when one wants to initialize an individual
VLC via one of the INIT_VLC macros as one just hardcodes the needed
size. Yet it is an obstacle when one wants to initialize several VLCs
in a loop as one then needs to add an array for the sizes/offsets of
the VLC tables (unless max_depth of all arrays is one in which case
the sizes are derivable from the number of bits used).
Yet said size array is not necessary if one disables the warning for too
big buffers. The reason is that the amount of entries needed for the
table is of course generated as a byproduct of initializing the VLC.
To this end a flag that disables the warning has been added.
So one can proceed as follows:
avcodec/tscc2: Reduce the size of the tables used to initialize VLCs
After permuting both the codes, lengths and symbols tables so that
the codes tables are ordered from left to right in the tree, the codes
tables can be easily computed from the lengths tables at runtime and
therefore omitted. This saves about 2KB from the binary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/bitstream: Add second function to create VLCs
When using ff_init_vlc_sparse() to create a VLC, three input tables are
used: A table for lengths, one for codes and one for symbols; the latter
one can be omitted, then a default one will be used. These input tables
will be traversed twice, once to get the long codes (which will be put
into subtables) and once for the small codes. The long codes are then
sorted so that entries that should be in the same subtable are
contiguous.
This commit adds an alternative to ff_init_vlc_sparse():
ff_init_vlc_from_lengths(). It is based upon the observation that if
lengths, codes and symbols tables are permuted (in the same way) so that
the codes are ordered from left to right in the corresponding tree and
if said tree is complete (i.e. every non-leaf node has two children),
the codes can be easily computed from the lengths and are therefore
redundant. This means that if one initializes such a VLC with explicitly
coded lengths, codes and symbols, the codes can be avoided; and even if
one has no explicitly coded symbols, it might still be beneficial to
remove the codes even when one has to add a new symbol table, because
codes are typically longer than symbols so that the latter often fit
into a smaller type, saving space.
Furthermore, given that the codes here are by definition ordered from
left to right, it is unnecessary to sort them again; for the same
reason, one does not have to traverse the input twice. This function
proved to be faster than ff_init_vlc_sparse() whenever it has been
benchmarked.
This function is usable for static tables (they can simply be permuted
once) as well as in scenarios where the tables are naturally ordered
from left to right in the tree; the latter e.g. happens with Smacker,
Theora and several other formats.
In order to make it also usable for (static) tables with incomplete trees,
negative lengths are used to indicate that there is an open end of a
certain length.
Finally, ff_init_vlc_from_lengths() has one downside compared to
ff_init_vlc_sparse(): The latter uses tables that can be reused by
encoders. Of course, one could calculate the needed table at runtime
if one so wishes, but it is nevertheless an obstacle.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/hls: Fixes overwriting existing #EXT-X-PROGRAM-DATE-TIME value in HLS playlist
fix ticket: 8989
This is is due to the following behavior in the current code:
1. The initial_prog_date_time gets set to the current local time
2. The existing playlist (.m3u8) file gets parsed and the segments
present are added to the variant stream
3. The new segment is created and added
4. The existing segments and the new segment are written to the
playlist file. The initial_prog_date_time from point 1 is used
for calculating "#EXT-X-PROGRAM-DATE-TIME" for the segments,
which results in incorrect "#EXT-X-PROGRAM-DATE-TIME" values
for existing segments
The following approach fixes this bug:
1. Add a new variable "discont_program_date_time" of type double
to HLSSegment struct
2. Store the "EXT-X-PROGRAM-DATE-TIME" value from the existing
segments in this variable
3. When writing to playlist file if "discont_program_date_time"
is set, then use that value for "EXT-X-PROGRAM-DATE-TIME" else
use the value present in vs->initial_prog_date_time
Philip Langdale [Sun, 6 Dec 2020 04:25:29 +0000 (20:25 -0800)]
avcodec/nvdec: Add support for decoding monochrome av1
The nvidia hardware explicitly supports decoding monochrome content,
presumably for the AVIF alpha channel. Supporting this requires an
adjustment in av1dec and explicit monochrome detection in nvdec.
I'm not sure why the monochrome path in av1dec did what it did - it
seems non-functional - YUV440P doesn't seem a logical pix_fmt for
monochrome and conditioning on chroma sub-sampling doesn't make sense.
So I changed it.
I've tested 8bit content, but I haven't found a way to create a 10bit
sample, so that path is untested for now.
avcodec/h264idct_template: Fix integer overflow in ff_h264_chroma422_dc_dequant_idct()
Fixes: signed integer overflow: -2105540608 - 2105540608 cannot be represented in type 'int' Fixes: 26870/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5656647567147008 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/av1dec: check size before addition in probing
Fixes: signed integer overflow: 175 + 2147483571 cannot be represented in type 'int' Fixes: 26833/clusterfuzz-testcase-minimized-ffmpeg_dem_IMAGE2_fuzzer-5969501214212096 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 46671062 * 100 cannot be represented in type 'int' Fixes: 26826/clusterfuzz-testcase-minimized-ffmpeg_dem_REALTEXT_fuzzer-5644062910316544 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Marton Balint [Sat, 31 Oct 2020 16:51:34 +0000 (17:51 +0100)]
avformat/dv: fix timestamps of audio packets in case of dropped corrupt audio frames
By using the frame counter (and the video time base) for audio pts we lose some
timestamp precision but we ensure that video and audio coming from the same DV
frame are always in sync.
This patch also makes timestamps after seek consistent and it should also fix
the timestamps when the audio clock is unlocked and have a completely
indpendent clock source. (E.g. runs on fixed 48009 Hz which should have been
exact 48000 Hz)
Limin Wang [Sun, 29 Nov 2020 00:07:46 +0000 (08:07 +0800)]
avdevice/decklink: remove the duplicated warning message
./ffmpeg -list_devices true -f decklink -i dummy
[Blackmagic DeckLink indev @ 0x2f96d00] The "list_devices" option is deprecated: list available devices
[decklink @ 0x2f96400] The -list_devices option is deprecated and will be removed. Please use ffmpeg -sources decklink instead.
->
[Blackmagic DeckLink indev @ 0x306ed00] The "list_devices" option is deprecated: use ffmpeg -sources decklink instead
Reviewed-by: Marton Balint <cus@passwd.hu> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
A reference to an AV1RawFrameHeader and consequently the
AV1RawFrameHeader itself and everything it has a reference to leak
if the hardware has no AV1 decoding capabilities or if some other error
happens. It happens e.g. in the cbs-av1-av1-1-b8-02-allintra FATE-test;
it has just been masked because the return value of ffmpeg (which
indicates failure when using Valgrind or ASAN) is ignored when doing
tests of type md5.
Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/mov: Avoid overflow in end computation in mov_read_custom()
Fixes: signed integer overflow: 18 + 9223372036854775799 cannot be represented in type 'long' Fixes: 26731/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5696846019952640 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Michael Koch [Fri, 4 Dec 2020 18:43:26 +0000 (19:43 +0100)]
avfilter/vf_v360: fix several problems with 'perspective' output
The image center wasn't preserved, the output image was mirror reversed,
and rotations were made around wrong axes.
I did also remove the vector normalization, because it's sure that the vector
is already normalized if it's calculated from sin() and cos() terms.
This function existed to enable codecs with non-threadsafe init functions
to initialize other codecs despite the fact that normally no two codecs
with non-threadsafe init functions can be initialized at the same time
(there is a mutex guarding this). Yet there are no users of this
function any more as all users have been made thread-safe (switching
away from ff_codec_open2_recursive() was required for this as said
function requires the caller to hold the lock to the mutex guarding the
initializations and this is only true for codecs with the
FF_CODEC_CAP_INIT_THREADSAFE flag unset); so remove it.
Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The only thing that stands in the way of adding the
FF_CODEC_CAP_INIT_THREADSAFE flag to the TIFF decoder is its usage
of ff_codec_open2_recursive(): This function requires its caller to hold
the lock for the mutex that guards initialization of AVCodecContexts
whose codecs have a non-threadsafe init function and only callers whose
codec does not have the FF_CODEC_CAP_INIT_THREADSAFE flag set hold said
lock (the others don't need to care about said lock). But one can set
the flag if one switches to avcodec_open2() at the same time.
Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The only thing that stands in the way of adding the
FF_CODEC_CAP_INIT_THREADSAFE flag to the SMV JPEG decoder is its usage
of ff_codec_open2_recursive(): This function requires its caller to hold
the lock for the mutex that guards initialization of AVCodecContexts
whose codecs have a non-threadsafe init function and only callers whose
codec does not have the FF_CODEC_CAP_INIT_THREADSAFE flag set hold said
lock (the others don't need to care about said lock). But one can set
the flag if one switches to avcodec_open2() at the same time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The only thing that stands in the way of adding the
FF_CODEC_CAP_INIT_THREADSAFE flag to the Cintel RAW decoder is its usage
of ff_codec_open2_recursive(): This function requires its caller to hold
the lock for the mutex that guards initialization of AVCodecContexts
whose codecs have a non-threadsafe init function and only callers whose
codec does not have the FF_CODEC_CAP_INIT_THREADSAFE flag set hold said
lock (the others don't need to care about said lock). But one can set
the flag if one switches to avcodec_open2() at the same time.
Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec: Fix invalid uses of ff_codec_open2_recursive()
Normally no two codecs with FF_CODEC_CAP_INIT_THREADSAFE unset
can be initialized at the same time: a mutex in avcodec_open2()
ensures this. This implies that one cannot simply open a codec
with a non-threadsafe init-function from the init function of
a codec whose own init function is not threadsafe either as the child
codec couldn't acquire the lock.
ff_codec_open2_recursive() exists to get around this limitation:
If the init function of the child codec to be initialized is not
thread-safe, the mutex is unlocked, the child is initialized and
the mutex is locked again. This of course has as a prerequisite that
the parent AVCodecContext actually holds the lock, i.e. that the
parent codec's init function is not thread-safe. If it is, then one
can (and has to) just use avcodec_open2() directly (if the child's
init function is not thread-safe, then avcodec_open2() will have to
acquire the mutex itself (and potentially wait for it), so that it is
perfectly fine for an otherwise thread-safe init function to open
a codec with a potentially non-thread-safe init function via
avcodec_open2()).
Yet several of the users of ff_codec_open2_recursive() have the
FF_CODEC_CAP_INIT_THREADSAFE flag set; this only worked because
all the child codecs' init functions were thread-safe themselves
so that ff_codec_open2_recursive() didn't touch the mutex at all.
But of course the real solution to this is to directly use
avcodec_open2().
Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This affected all decoders that used ff_mjpeg_decode_init() as init
function; and it also affected decoders that open jpeg decoders via
ff_codec_open2_recursive() as well as MxPEG.
Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
projects / ffmpeg / log