On Mon, 30 Jan 2017, Rostislav Pehlivanov wrote:
On 30 January 2017 at 00:09, 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?
Thanks,
Marton
The memory referenced by the AVFrame can be e.g. in hardware or used by
something else. It makes no sense to try to write to it, you'd just mess up
whatever else the user is using the data for.
So you allocate new buffers, make a copy of the data and unref the ref you
have.
I don't follow. The code above is also doing that, making writable all
the AVBufferRef-s, therefore allocating a new buffer for them, copying
their content to the newly allocated buffer, and unrefing the old buffer.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
