[FFmpeg-devel] [PATCH] avcodec/h264_slice: don't copy frame data during error concealment

[Xu, Guangxin]

We will test vaapi for this patch.
 
But I am more curious about the software decoder behaviors.
This approach just ref the yuv. Not the intermedia data(like mv,  macroblock type)
Will it have problem if missed frame selected as colPic (Figure 8-2 in spec).

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Hendrik Leppkes
> Sent: Tuesday, March 9, 2021 3:44 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: don't copy frame
> data during error concealment
> 
> On Tue, Mar 9, 2021 at 3:39 AM James Almer <jamrial at gmail.com> wrote:
> >
> > In addition to the fact that av_image_copy() cannot handle hardware
> > pixel formats, h->short_ref[0]->f may not even be writable at this point.
> >
> > Based on a patch by Hendrik Leppkes.
> >
> > Signed-off-by: James Almer <jamrial at gmail.com>
> > ---
> > This is an alternative to "avcodec/h264_slice: properly handle missing
> > reference frames with hwaccel", given that I noticed that the target
> > frame is not writable for example when running fate-h264-missing-frame.
> >
> > To keep the current behavior of copying the frame data instead of
> > making a reference, I also tried to do ff_thread_release_buffer() ->
> > ff_thread_get_buffer() -> av_frame_copy(), which worked with software
> > decoding, but when using the d3d11va hwaccel the av_frame_copy() call
> would fail.
> >
> > There is a warning above this code that makes it sound like making
> > references is not ideal, but considering h->short_ref[0] is not
> > writable here it feels like it could be an outdated comment that someone
> forgot to remove.
> >
> 
> Looks more thorough then my original change. I was worried about the
> comment also, but I think it may have been from before the days of ref-
> counting, frame threading, and all that (the comment appeared with the
> original code in e2983d6eac7b0bb563886c6f97c4ce0385b2018d, 2010)
> 
> Perhaps the comment should be removed if we are going to reference now
> anyway?
> 
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email ffmpeg-devel-request at ffmpeg.org
> with subject "unsubscribe".