From: David Rosca <nowrep@gmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_h264: Don't try to merge fields in DPB for non-field pics Date: Tue, 7 May 2024 08:02:48 +0200 Message-ID: <CAM7PDoiNF16bR7k39NzqBCZ9wP4otSTpU+qc4WkLxz9=9htMeA@mail.gmail.com> (raw) In-Reply-To: <6dff879e-9748-4b9e-bf09-1e1e0785eb4c@jkqxz.net> On Mon, May 6, 2024 at 9:55 PM Mark Thompson <sw@jkqxz.net> wrote: > > On 05/05/2024 17:36, David Rosca wrote: > > This path can be hit when there are missing references while decoding > > progressive stream and would completely break the DPB contents. > > --- > > libavcodec/vaapi_h264.c | 30 ++++++++++++++++-------------- > > 1 file changed, 16 insertions(+), 14 deletions(-) > > Can you share a stream which does this in a progressive case? https://github.com/nowrep/chiaki4deck/raw/samples/samples/missingframes.h264 > > My understanding of this (though I suspect I am missing something) is that we are filling from the short/long DPB lists which should not contain duplicates (not RefPicListX, which can), so I'm not seeing how this case could be triggered. > > If you do have two DPB entries which are different frames but refer to the same surface then that seems like a bug elsewhere. It comes from the error concealment in h264dec which copies previous ref for missing refs. It can actually also happen for interlaced streams. I've sent a new patch that should fix it for both progressive and interlaced. https://github.com/FFmpeg/FFmpeg/blob/b1037d4ebe7b7f9548ce1ed24a2929aedbe9a27a/libavcodec/h264_slice.c#L1520-L1559 Thanks, David > > Thanks, > > - Mark > > > > diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c > > index b47531ce1c..ca0076f57a 100644 > > --- a/libavcodec/vaapi_h264.c > > +++ b/libavcodec/vaapi_h264.c > > @@ -98,22 +98,24 @@ static int dpb_add(DPB *dpb, const H264Picture *pic) > > if (dpb->size >= dpb->max_size) > > return -1; > > > > - for (i = 0; i < dpb->size; i++) { > > - VAPictureH264 * const va_pic = &dpb->va_pics[i]; > > - if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f)) { > > - VAPictureH264 temp_va_pic; > > - fill_vaapi_pic(&temp_va_pic, pic, 0); > > - > > - if ((temp_va_pic.flags ^ va_pic->flags) & (VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD)) { > > - va_pic->flags |= temp_va_pic.flags & (VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD); > > - /* Merge second field */ > > - if (temp_va_pic.flags & VA_PICTURE_H264_TOP_FIELD) { > > - va_pic->TopFieldOrderCnt = temp_va_pic.TopFieldOrderCnt; > > - } else { > > - va_pic->BottomFieldOrderCnt = temp_va_pic.BottomFieldOrderCnt; > > + if (pic->field_picture) { > > + for (i = 0; i < dpb->size; i++) { > > + VAPictureH264 * const va_pic = &dpb->va_pics[i]; > > + if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f)) { > > + VAPictureH264 temp_va_pic; > > + fill_vaapi_pic(&temp_va_pic, pic, 0); > > + > > + if ((temp_va_pic.flags ^ va_pic->flags) & (VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD)) { > > + va_pic->flags |= temp_va_pic.flags & (VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD); > > + /* Merge second field */ > > + if (temp_va_pic.flags & VA_PICTURE_H264_TOP_FIELD) { > > + va_pic->TopFieldOrderCnt = temp_va_pic.TopFieldOrderCnt; > > + } else { > > + va_pic->BottomFieldOrderCnt = temp_va_pic.BottomFieldOrderCnt; > > + } > > } > > + return 0; > > } > > - return 0; > > } > > } > > > _______________________________________________ > 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".
prev parent reply other threads:[~2024-05-07 6:03 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-05-05 16:36 David Rosca 2024-05-06 19:55 ` Mark Thompson 2024-05-07 6:02 ` David Rosca [this message]
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='CAM7PDoiNF16bR7k39NzqBCZ9wP4otSTpU+qc4WkLxz9=9htMeA@mail.gmail.com' \ --to=nowrep@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