The MPEG-1 decoder has an update_thread_context function set,
yet it was never enabled (missing AV_CODEC_CAP_FRAME_THREADS
flag). So remove it and also the ff_thread_finish_setup() call
as well as the progress reporting.
(Simply setting the flag would not be enough. The main problems
are:
a) The update_thread_context function relies on memcpy'ing
the whole context instead of only copying the necessary fields.
This leads to data races which is undefined behaviour.
(Btw: The check for whether the non-MpegEncContext fields
of Mpeg1Context should be copied has been broken in
7f0efe232475d7a704924a3cb308281973e8add3.)
b) Even an AVBufferRef* is simply copied, without creating a new
reference.
c) Copying the whole context happens only during init; when parameters
change lateron, the change is not propagated to the next thread.
This affects at least the quant matrix (for MPEG-1).
d) The MPEG-1/2 decoders are made to decode both MPEG-1 and MPEG-2.
When MPEG-2 is decoded, another complication arises: In case of
coded fields, both fields can be in one AVPacket or they can be
in separate AVPackets. One would need to parse enough of the data
to be able to determine whether the next thread needs to start
a new frame or decode the second field of the current frame;
for this one would need to either postpone calling
ff_thread_finish_setup() for coded slices altogether or implement
some form of ff_h2645_packet_split().
One would also need a second ThreadProgress to signal progress
of each field.
e) One would need to reenable waiting in ff_mpv_reconstruct_mb()
for MPEG-1/2 (and H.261).
f) Probably lots of other stuff for invalid input that I am currently
not thinking about.
If this were done, nothing from the current update_thread_context
would remain, so one can just nuke it altogether.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Call ff_mpeg_update_thread_context() first and
update the RV34 buffers if it indicates a reinitialization.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
