Namely of reinititialization performed by
ff_mpeg_update_thread_context(), so that they can simply
update their own dimension-based buffers accordingly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by the MPEG-4 decoder and the encoders.
Notice that this field is a per-frame property and therefore
does not need to by synced in mpeg4_update_thread_context().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Namely in ff_mpeg4_get_video_packet_prefix_length().
This will allow to move [fb]_code from MpegEncContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When switching to the XviD IDCT, the IDCT permutation can change.
Given that we already permute the quant matrices when parsing
them, they need to be permuted, too. Up until now this has not been
done; instead the header has been parsed again in the expectation
that the currently active quant matrix is contained in this header.
This expectation is wrong; it is for example wrong when the VOL
header is only available via extradata (such a file can be easily
created from xvid_vlc_trac7411.h263 (in the FATE suite) via the
remove_extra BSF). It could also be wrong if the XviD user data
is only available in a subsequent packet.
This commit therefore switches to permuting the relevant matrices
directly. It also stops parsing the header a second time
when switching to the XviD IDCT.
(I wonder whether ff_mpv_idct_init() should take alternate_scan
into account when initializing permutated_intra_h_scantable
as the decoder does. Does the MPEG-4 encoder use a wrong scantable
in this case?)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It does not change lateron.
(If we were to add short header support later, it would involve
a branch in mpeg4_decode_block() anyway and we would then
hardcode the dc_scaler value of eight there; the *_scale_tables
would stay the same.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We never set the ThreadFrame*, because mpegvideo uses
ThreadProgress instead of ThreadFrames. Furthermore,
it is unnecessary because the ERPicture has just been zeroed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_xvid_idct_init() already checks in case of high_bit_depth,
lowres or an incompatible idct_algo.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The key benefits are:
- Different to other graph printing methods, this is outputting:
- all graphs with runtime state
(including auto-inserted filters)
- each graph with its inputs and outputs
- all filters with their in- and output pads
- all connections between all input- and output pads
- for each connection:
- the runtime-negotiated format and media type
- the hw context
- if video hw context, both: hw pixfmt + sw pixfmt
- Output can either be printed to stdout or written to specified file
- Output is machine-readable
- Use the same output implementation as ffprobe, supporting multiple
formats
Signed-off-by: softworkz <softworkz@hotmail.com>
Compression requires zlib to be available, otherwise resources will
be included uncompressed - in either case via BIN2C.
It can also be disabled via
./configure --disable-resource-compression
Size figures:
graph.css 7752
graph.css.min 6655 (css is always minified)
graph.html 2153
No Compression
graph.css.c 40026
graph.css.o 9344 (6688)
graph.html.c 13016
graph.html.o 4848 (2186)
With Compression
graph.css.c 10206
graph.css.o 4368 (1718)
graph.html.c 5725
graph.html.o 3632 (971)
Numbers in brackets: .rodata size from 'size -Ax -d *.o'
Signed-off-by: softworkz <softworkz@hotmail.com>
Also change writer_printf signature in AVTextWriter to use va_list,
so that it can be called by the new function writer_printf()
in tf_internal.h.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
This allows future addition of options without
changes to the signature of avtext_context_open().
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Instead of initializing a new BPrint in case of UTF decode error,
re-use the same BPrint struct and just clear it
for each iteration.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: softworkz <softworkz@hotmail.com>
Fixes: signed integer overflow: -1384566925600903168 * 16 cannot be represented in type 'long'
Fixes: 407069502/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-5159255372267520
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The encoder uses max 128 taps, which is quiet a lot already
If work is done to improve sonic, it will be more radical than changing the taps
Fixes: Timeout
Fixes: 402539974/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SONIC_fuzzer-6122944271286272
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is based on discussion with the GA and its simply the people
who have done or tried to do some uploads recently.
Everyone who has a shell account on ffmpeg.org should have powers to
upload samples.
CC: compn <compn@ffmpeg.org>
CC: Thilo Borgmann <thilo.borgmann@mail.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now if avcodec_send_packet() returned an error,
no attempt to receive a frame from the decoder would be made.
Instead the decoder was presumed to be drained, so that more
packets could be sent to it. Yet this need not be so:
It can happen that a packet would decode to multiple frames
and that decoding the first of these (the one that is decoded
during the avcodec_send_packet() call) returns an error,
in which case the decoder is not yet ready to receive more
input as the remaining parts of the packet have not been decoded
yet. In this case, an AERROR_BUG is triggered.
This happens in ticket #11553 with VP9 (which uses a BSF
to split VP9 superframes and is therefore affected by this).
Fix this by always calling avcodec_receive_frame() unless
xerror is set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AV1DemuxContext.temporal_unit_size is zero after reading the header,
so the position set when reading the header will not be used at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
