On Thu, Mar 24, 2022 at 09:20:06PM +0100, Andreas Rheinhardt wrote:
> 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 43b434210e597d484aef57c4139c3126d22b7e2b
> (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.
> 
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
> ---
>  libavcodec/h264_slice.c | 7 -------
>  1 file changed, 7 deletions(-)

this patchset is a nice cleanup/fix to the error concealment code
in h264

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.