ff_er_frame_start() initializes ERContext.error_count
to three times the number of macroblocks to decode.
Later ff_er_add_slice() reduces this number by the amount
of macroblocks whose AC resp. DC resp. MV have been finished
(so every correctly decoded MB counts three times).
So the frame has been decoded correctly if error_count is zero
at the end.
The H.264 decoder uses multiple ERContexts when using
slice threading and therefore combines these error counts:
The first slice's ERContext is intended to be initialized
by ff_er_frame_start(), error_count of all the other
slice contexts is intended to be zeroed initially and
all afterwards all the error_counts are summed.
Yet commit 43b434210e
(probably unintentionally) changed the code to set
the first slice's error_count to zero as well.
This leads to bogus error messages in case one decodes
an input video using multiple slices with slice threading
with error concealment enabled (which is not the default)
("concealing 0 DC, 0 AC, 0 MV errors in [IPB] frame");
furthermore the returned frame is marked as corrupt as well
(ffmpeg reports "corrupt decoded frame in stream %d" for this).
This can be fixed easily given that only the first ERContext
is really used since 7be2d2a70cd20d88fd826a83f87037d14681a579:
Don't reset the error_count; and don't sum the error counts as well.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Look for the generic "USR" labels instead of "?" to skip channels with no
known names, and actually print the decomposition of standard channel layouts.
Signed-off-by: James Almer <jamrial@gmail.com>
This patch is analogous to 20f972701806be20a77f808db332d9489343bb78:
It hides the internal part of AVBitStreamFilter by adding a new
internal structure FFBitStreamFilter (declared in bsf_internal.h)
that has an AVBitStreamFilter as its first member; the internal
part of AVBitStreamFilter is moved to this new structure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All FF_QSCALE_TYPE values used by libavfilter originate
from libavfilter (namely from ff_qp_table_extract());
no value is exchanged between libavcodec and libavutil.
The values that are exchanged (and used in libavfilter)
are of type enum AVVideoEncParamsType.
Therefore this patch stops using said FF_QSCALE_TYPE_*
in libavfilter and uses enum AVVideoEncParamsType
directly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Especially useful when debugging subtitle output, but also shows
if values are set or not for demux and encoding.
Co-authored-by: Jan Ekström <jan.ekstrom@24i.com>
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Otherwise get_pixel_format() will not be called when parsing a subsequent Sequence
Header in non hwaccel enabled scenarios, allowing frame parsing when it shouldn't.
This prevents the scenario seqhdr -> frame_hdr/redundant_frame_hdr -> seqhdr ->
redundant_frame_hdr from having the latter redundant frame header parsed as if it
was a frame header by the decoder because the former was discarded.
Since CBS did not discard it, the latter redundant frame header is output with a
zeroed AV1RawFrameHeader struct, which can have undesired results, like division
by zero with fields normally guaranteed to be anything else.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Due to a quirk of the ASS format some tags depend on the exact storage
resolution of the video, so tell libass via ass_set_storage_size.
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
It allocates a dummy sws/swr context and tries setting options on it,
apparently to check if they are valid. This is redundant, since the
options will be checked if/when they are later applied on a context that
is actually used for conversion.
It tries to process any unhandled options as AVOptions. Handle this
directly in cmdutils.c, without resorting to a confusing fake option
definition (which is currently visible to the users in -help output).
Fix below error message when timecode packet is written.
"Application provided duration: -9223372036854775808 / timestamp: -9223372036854775808 is out of range for mov/mp4 format"
try to reproduce by:
ffmpeg -y -f lavfi -i color -metadata "timecode=00:00:00:00" -t 1 test.mov
Note although error message is printed, the timecode packet will be written anyway. So
the patch 2/2 will try to change the log level to warning.
Fixes ticket #9488
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Andreas Rheinhardt
Paul B Mahol
James Almer
Gyan Doshi
Jaakko Perttilä
Christopher Degawa
Oneric
Anton Khirnov
Zhao Zhili
Limin Wang