When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data by using
ff_get_encode_buffer() and also set AV_CODEC_CAP_DR1 at the same time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data; this also makes it easy
to allow user-supplied buffers. Only one thing needed to be changed:
One can no longer use a pointer to uint16_t for the destination buffer
because its alignment is unknown.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data by using
ff_get_encode_buffer() and also set AV_CODEC_CAP_DR1 at the same time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data by using
ff_get_encode_buffer() and also set AV_CODEC_CAP_DR1 at the same time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the cljr encoder used buffers that were too big by a
factor of eight (probably bit/byte confusion). This has been fixed.
And because the needed buffer size can be easily calculated in advance,
one can avoid the implicit use of an intermediate buffer and can even
allow user-supplied buffers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data; this also makes it easy
to allow user-supplied buffers. Only one thing needed to be changed:
One can no longer use a pointer to uint16_t for the destination buffer
because its alignment is unknown.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data by using
ff_get_encode_buffer() and also set AV_CODEC_CAP_DR1 at the same time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data by using
ff_get_encode_buffer() and also set AV_CODEC_CAP_DR1 at the same time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The size of the output buffer is always known in advance and
the code has no alignment requirement (it uses mostly the PutBits API),
so allowing user-supplied buffers is trivial.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data; and one can also use
user-supplied buffers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data by using
ff_get_encode_buffer() and also set AV_CODEC_CAP_DR1 at the same time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: signed integer overflow: -635424002382840000 * 16 cannot be represented in type 'long'
Fixes: 33612/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-5704741108711424
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There are cases where using 1000 as the MP4 timescale is not
accurate enough, for example when one needs sample-accurate audio
handling.
This adds a new AVOption to the MOV/MP4 muxer to override the
movie timescale, but it still defaults to 1000 to maintain current
default behavior.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This simply performs a 2nd pass if a LSE is encountered with GRAY8
Fixes: tickets/3933/128.jls
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use AVSTREAM_EVENT_FLAG_NEW_PACKETS instead, which should provide the
same information in this case.
Finishes removing all uses of this field as started by 87f0c8280c.
Signed-off-by: James Almer <jamrial@gmail.com>
The MLP/TrueHD encoder uses pointers to non-const to access several
static objects that are only initialized at runtime and are therefore
not declared as const. This does not result in compiler warnings, but it
is fragile, as these objects are really not to be modified as they are
not owned by any encoder instance. Therefore this commit adds const to
the pointed to type of the pointers used to access them after their
initialization. One object has even been made const.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The size of ff_qexp is only 32 bytes, but the code to generate it at
runtime takes 47 bytes (GCC 9.3, x64, -O3 in an av_cold function); so
just hardcode it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Bink video decoder uses VLCs; the longest codes of these VLCs have
different lengths, yet they are all so small that each VLC is read in
one go, so that the number of elements in the VLC table actually used by
each table is 1 << nb_bits, where nb_bits is the length of the longest
code. Yet when determining the size of the VLC table nb_bits has been
overestimated as the number of bits of the longest code in all VLCs,
making said table unnecessary big (2048 vs 976 elements).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ff_ass_subtitle_header_full() just uses av_asprintf() and is therefore
thread-safe itself.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Note: This decoder uses a static variable in save_display_set() (which
is only enabled if DEBUG is defined); yet said function can't be reached
from the decoder's init function at all, so it is no problem for
setting the FF_CODEC_CAP_INIT_THREADSAFE flag.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These pointers sometimes point to static storage (namely to
default_clut), so adding const to the pointed-to type is important to
ensure that one does not accidentally modify something that is not owned
by a single AVCodecContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>