On 28/03/2024 02:56, arch1t3cht wrote:
Fix one or more frames being dropped when starting decoding at a SEI
recovery point that is very close to the end of the stream
(specifically, which is less than 2 * has_b_frames frames before the
end of the stream in decoding order). One case of this was reported
in ticket #10936.
Tested for regressions using FATE. If necessary I can also try to add
a test for the previously broken behavior.
There's now a bit of code duplication between
h264_select_output_frame and send_next_delayed_frame (or, rather,
there was already some code duplication and this patch
adds a bit more). But this probably cannot be avoided without a larger
refactor to, say, also call h264_select_output_frame in
send_next_delayed_frame instead of manually selecting a frame, which
I don't feel confident enough to do myself.
arch1t3cht (3):
avcodec/h264dec: Properly mark frames as recovered when draining
avcodec/h264dec: Handle non-recovered frames when draining
avcodec/h264dec: Reindent after the previous commit
libavcodec/h264dec.c | 44 ++++++++++++++++++++++++++------------------
1 file changed, 26 insertions(+), 18 deletions(-)
Can I bump this? It's my first time sending a patch here so let me know
if I did something wrong.
-arch1t3cht
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
