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