Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Using one big table for the codebook symbols and lengths makes it
possible to remove the pointers to the individual tables.
Signed-off-by: NAndreas 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: NAndreas 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: NAndreas 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: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Also use a named constant for the number of bits of the VLC tables.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

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:

static VLC vlcs[NUM];
static VLC_TYPE vlc_table[BUF_SIZE][2];

for (int i = 0, offset = 0; i < NUM; i++) {
    vlcs[i].table           = &vlc_table[offset];
    vlcs[i].table_allocated = BUF_SIZE - offset;
    init_vlc(); /* With INIT_VLC_STATIC_OVERLONG flag */
    offset += vlcs[i].table_size;
}

Of course, BUF_SIZE should be equal to the number of entries actually
needed.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Using one big table for the symbols and lengths makes it
possible to remove the pointers to the individual tables.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

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: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

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: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

the init.mp4 can be expanded with strftime the same way as
hls_segment_filename.
Signed-off-by: NNikola Pajkovsky <nikola@pajkovsky.cz>
Signed-off-by: Nliuqi05 <liuqi05@kuaishou.com>

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
Signed-off-by: NVignesh Ravichandran <vignesh.ravichandran02@gmail.com>
Signed-off-by: Nliuqi05 <liuqi05@kuaishou.com>

Previous filter output was incorrect. New one actually follows
graph in comments described on side of filter taps.

Signed-off-by: NJames Almer <jamrial@gmail.com>

Create a local one instead from a byte buffer input argument.
This prevents skipping bytes that may belong to another SEI message.
Signed-off-by: NJames Almer <jamrial@gmail.com>

Signed-off-by: NJames Almer <jamrial@gmail.com>

Signed-off-by: NJames Almer <jamrial@gmail.com>

As this is a meta muxer and the same flag is set with the fifo
meta muxer, there is really no reason not to have this set here
as well.
Signed-off-by: NJan Ekström <jan.ekstrom@24i.com>

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.

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/ffmpegSigned-off-by: NMichael Niedermayer <michael@niedermayer.cc>

Fixes: infinite loop
Fixes: 26865/clusterfuzz-testcase-minimized-ffmpeg_dem_DSF_fuzzer-5649473830912000

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: NMichael Niedermayer <michael@niedermayer.cc>

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/ffmpegSigned-off-by: NMichael 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/ffmpegSigned-off-by: NMichael Niedermayer <michael@niedermayer.cc>

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)

Fixes out of sync timestamps in ticket #8762.
Signed-off-by: NMarton Balint <cus@passwd.hu>

Signed-off-by: NJames Almer <jamrial@gmail.com>

Signed-off-by: NJames Almer <jamrial@gmail.com>

Signed-off-by: NJames Almer <jamrial@gmail.com>

Signed-off-by: NPeter Ross <pross@xvid.org>

Signed-off-by: NPeter Ross <pross@xvid.org>

Same as when downloading. Not sure why this isn't done, probably
because the CUDA code predates the sync mechanism we settled on.

Signed-off-by: NJames Almer <jamrial@gmail.com>

Signed-off-by: NJames Almer <jamrial@gmail.com>

Signed-off-by: NJames Almer <jamrial@gmail.com>

Signed-off-by: NJames Almer <jamrial@gmail.com>