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?
Thanks,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
