On Mon, Apr 11, 2022 at 03:01:57PM -0300, James Almer wrote: > > > On 4/11/2022 10:31 AM, Michael Niedermayer wrote: > > Fixes: issues with non trivial linesize > > > > Signed-off-by: Michael Niedermayer > > --- > > libavfilter/vf_frei0r.c | 40 ++++++++++++++++++++++++++++++++-------- > > 1 file changed, 32 insertions(+), 8 deletions(-) > > > > diff --git a/libavfilter/vf_frei0r.c b/libavfilter/vf_frei0r.c > > index 9cd0098e73..c9b698897f 100644 > > --- a/libavfilter/vf_frei0r.c > > +++ b/libavfilter/vf_frei0r.c > > @@ -349,18 +349,41 @@ static int query_formats(AVFilterContext *ctx) > > return ff_set_common_formats(ctx, formats); > > } > > +static AVFrame *getframe(AVFilterLink *link) > > +{ > > + int ret; > > + AVFrame *frame = av_frame_alloc(); > > + if (!frame) > > + return NULL; > > + > > + frame->width = link->w; > > + frame->height = link->h; > > + frame->format = link->format; > > + ret = av_frame_get_buffer(frame, 16); > > Maybe ff_get_video_buffer can be updated to accept an align argument which > would be used instead of av_cpu_max_align() when not 0, so we don't lose the > benefits of the frame pool it provides? We need a specific alignment and specific linesize. ff_get_video_buffer() is forwarded to the next filter so a change to it feels moderately messy. Each filter using it would have to deal with specific linesize and alignment requirements. Thats for one odd filter What can be done is to work with ff_default_get_video_buffer() maybe and never use the next filters one. Ill send a patch doing that if it pases tests thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2