From: Hendrik Leppkes <h.leppkes@gmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references Date: Tue, 14 Nov 2023 18:32:19 +0100 Message-ID: <CA+anqdyhXsZSkG3Gne6QDFTQ07dmn4fN93OeTuYXZCYneu39cg@mail.gmail.com> (raw) In-Reply-To: <20231114172051.13872-4-michael@niedermayer.cc> On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer <michael@niedermayer.cc> wrote: > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > --- > libavcodec/h264_picture.c | 1 + > libavcodec/h264_slice.c | 19 ++++++++++++++++++- > libavcodec/h264dec.c | 1 + > libavcodec/h264dec.h | 4 ++++ > 4 files changed, 24 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c > index 691c61eea23..3234141dbd6 100644 > --- a/libavcodec/h264_picture.c > +++ b/libavcodec/h264_picture.c > @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture *dst, const H264Picture *src) > dst->field_picture = src->field_picture; > dst->reference = src->reference; > dst->recovered = src->recovered; > + dst->gray = src->gray; > dst->invalid_gap = src->invalid_gap; > dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt; > dst->mb_width = src->mb_width; > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c > index 4861a2cabba..2c4ab89dae1 100644 > --- a/libavcodec/h264_slice.c > +++ b/libavcodec/h264_slice.c > @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst, > h->poc.prev_frame_num = h->poc.frame_num; > > h->recovery_frame = h1->recovery_frame; > + h->non_gray = h1->non_gray; > > return err; > } > @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h, const H264SliceContext *sl, > if (ret < 0) > return ret; > h->short_ref[0]->poc = prev->poc + 2U; > + h->short_ref[0]->gray = prev->gray; > ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 0); > if (h->short_ref[0]->field_picture) > ff_thread_report_progress(&h->short_ref[0]->tf, INT_MAX, 1); > - } else if (!h->frame_recovered && !h->avctx->hwaccel) > + } else if (!h->frame_recovered && !h->avctx->hwaccel) { > color_frame(h->short_ref[0]->f, c); > + h->short_ref[0]->gray = 1; > + } While we can't color invalid frames for hwaccels easily, the flag should perhaps still be applied, as they are equally invalid. Thinking about this, maybe the name should be less the color we happened to use for it, and more like "placeholder" or "invalid" or anything like that? > h->short_ref[0]->frame_num = h->poc.prev_frame_num; > } > } > @@ -2007,6 +2011,19 @@ static int h264_slice_init(H264Context *h, H264SliceContext *sl, > (sl->ref_list[j][i].reference & 3); > } > > + if (sl->slice_type_nos == AV_PICTURE_TYPE_I) { > + h->cur_pic_ptr->gray = 0; > + h->non_gray = 1; > + } else { > + int gray = 0; > + for (j = 0; j < sl->list_count; j++) { > + for (i = 0; i < sl->ref_count[j]; i++) { > + gray |= sl->ref_list[j][i].parent->gray; > + } > + } > + h->cur_pic_ptr->gray = gray; > + } > + > if (h->avctx->debug & FF_DEBUG_PICT_INFO) { > av_log(h->avctx, AV_LOG_DEBUG, > "slice:%d %c mb:%d %c%s%s frame:%d poc:%d/%d ref:%d/%d qp:%d loop:%d:%d:%d weight:%d%s %s\n", > diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c > index ef9e60bbf33..7ea55db75dd 100644 > --- a/libavcodec/h264dec.c > +++ b/libavcodec/h264dec.c > @@ -492,6 +492,7 @@ static void h264_decode_flush(AVCodecContext *avctx) > ff_h264_unref_picture(&h->cur_pic); > > h->mb_y = 0; > + h->non_gray = 0; > > ff_h264_free_tables(h); > h->context_initialized = 0; > diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h > index ede51951727..366626c056c 100644 > --- a/libavcodec/h264dec.h > +++ b/libavcodec/h264dec.h > @@ -154,6 +154,8 @@ typedef struct H264Picture { > > /// RefStruct reference; its pointee is shared between decoding threads. > atomic_int *decode_error_flags; > + > + int gray; > } H264Picture; > > typedef struct H264Ref { > @@ -567,6 +569,8 @@ typedef struct H264Context { > struct FFRefStructPool *ref_index_pool; > struct FFRefStructPool *decode_error_flags_pool; > int ref2frm[MAX_SLICES][2][64]; ///< reference to frame number lists, used in the loop filter, the first 2 are for -2,-1 > + > + int non_gray; ///< Did we encounter a intra frame after a gray gap frame > } H264Context; > > extern const uint16_t ff_h264_mb_sizes[4]; > -- > 2.17.1 > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2023-11-14 17:32 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-14 17:20 [FFmpeg-devel] [PATCH 1/6] avcodec/h264: Seperate SEI and IDR recovery handling Michael Niedermayer 2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 2/6] avcodec/h264: Use FRAME_RECOVERED_HEURISTIC instead of IDR/SEI Michael Niedermayer 2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 3/6] avcodec/h264dec: More elaborate documentation for frame_recovered Michael Niedermayer 2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references Michael Niedermayer 2023-11-14 17:32 ` Hendrik Leppkes [this message] 2023-11-14 18:46 ` Michael Niedermayer 2023-11-20 0:11 ` Michael Niedermayer 2023-11-20 3:01 ` Vittorio Giovara 2023-11-20 23:53 ` Michael Niedermayer 2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 5/6] avcodec/h264: Avoid using gray gap frames as references Michael Niedermayer 2023-11-21 12:27 ` James Almer 2023-11-22 0:09 ` Michael Niedermayer 2023-11-14 17:20 ` [FFmpeg-devel] [PATCH 6/6] avcodec/h264dec: Support skipping frames that used gray gap frames Michael Niedermayer 2023-11-21 12:28 ` James Almer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CA+anqdyhXsZSkG3Gne6QDFTQ07dmn4fN93OeTuYXZCYneu39cg@mail.gmail.com \ --to=h.leppkes@gmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git