[FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument

wm4 nfxjfg at googlemail.com
Mon Jan 30 08:42:35 EET 2017


On Mon, 30 Jan 2017 01:09:27 +0100 (CET)
Marton Balint <cus at passwd.hu> wrote:

> On Sat, 28 Jan 2017, Nicolas George wrote:
> 
> > Le nonidi 9 pluviôse, an CCXXV, Muhammad Faiz a écrit :  
> >> so the behavior will be similar to
> >> av_frame_make_writable().  
> >
> > The point was to move away from that. Who copies a struct when you can
> > move a pointer?
> >  
> 
> By the way, why av_frame_make_writable copies the struct?
> 
> As far as I see it can be implemented just like this:
> 
> int av_frame_make_writable(AVFrame *frame)
> {
>      int ret;
>      int i;
> 
>      if (!frame->buf[0])
>          return AVERROR(EINVAL);
> 
>      for (i = 0; i < FF_ARRAY_ELEMS(frame->buf); i++) {
>          if (frame->buf[i]) {
>              ret = av_buffer_make_writable(&frame->buf[i]);
>              if (ret < 0)
>                  return ret;
>              frame->data[i] = frame->buf[i]->data;
>          }
>      }
>      for (i = 0; i < frame->nb_extended_buf; i++) {
>          ret = av_buffer_make_writable(&frame->extended_buf[i]);
>          if (ret < 0)
>              return ret;
>          frame->extended_data[i] = frame->extended_buf[i]->data;
>      }
> 
>      return 0;
> }
> 
> It even passes fate. What do I miss?
> 
> Don't get me wrong, I know that this approach cannot be implemented 
> directly into the filtering case, because of the custom get buffer 
> callback and the frame pool, but for the generic frame function, is there 
> any downside doing this?

data[i] doesn't have to point to the start of buf[i]. Also multiple
planes can be in the same buffer. I guess the function is implemented
this way because that's the simplest.



More information about the ffmpeg-devel mailing list