On Mon, 30 Jan 2017 01:09:27 +0100 (CET)
Marton Balint <c...@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
