[FFmpeg-devel] [PATCH v2 1/1] avcodec/vpp_qsv: Copy side data from input to output frame

Soft Works softworkz at hotmail.com
Tue Dec 7 11:03:28 EET 2021



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Anton
> Khirnov
> Sent: Tuesday, December 7, 2021 9:08 AM
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/1] avcodec/vpp_qsv: Copy side data
> from input to output frame
> 
> Quoting Soft Works (2021-12-03 09:51:13)
> > > I'm concerned that this behavior will become hardcoded into this new API
> > > and we won't be able to get rid of it in the future.
> >
> > I understand your concern from an abstract point of view. But the point
> > about which you want to be concerned has already happened 7 years ago
> > and now there exist more than 200 usages of av_frame_copy_props(), all
> > of which are possibly expecting the special treatment of PANSCAN.
> > That makes me wonder, whether there might be any practical use for
> > a function av_frame_copy_side_data() that behaves differently?
> 
> I suspect the overwhelming majority of these calls are done between the
> frames with the same resolution, so the relevant code is not executed.
> The places where it does matter should be quite few.
> 
> And more generally, there's a lot of stuff in our codebase that
> shouldn't be there. We shouldn't give up on improving things just
> because they have been around for a long time.

I'm totally with you. I mean, I've gone over 4 patch versions just for improving
the documentation of the linesize[] parameter ;-)

You didn't quote the other part where I said that it might more sense to
investigate the PANSCAN story directly.
Anyway, I think the solution with the flags is good now.

softworkz


More information about the ffmpeg-devel mailing list