Le duodi 2 germinal, an CCXXIII, Ronald S. Bultje a écrit :
> ---
> libavutil/frame.c | 171
> +++++++++++++++++++++++++++++++-----------------------
> libavutil/frame.h | 1 +
> 2 files changed, 98 insertions(+), 74 deletions(-)
What consequences does it have for API users ? If there are not, do you know
why it was not done from the start?
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 12fe0a6..4596927 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -115,7 +115,7 @@ static void free_side_data(AVFrameSideData **ptr_sd)
> {
> AVFrameSideData *sd = *ptr_sd;
>
> - av_freep(&sd->data);
> + av_buffer_unref(&sd->buf);
> av_dict_free(&sd->metadata);
> av_freep(ptr_sd);
> }
> @@ -275,6 +275,91 @@ int av_frame_get_buffer(AVFrame *frame, int align)
> return AVERROR(EINVAL);
> }
>
> +static int frame_copy_props(AVFrame *dst, const AVFrame *src, int force_copy)
I had to look carefully to understand the move of code here. If it is not
too much trouble, could you consider splitting this part into a preliminary
patch, something like that:
# lavu/frame: wrap av_frame_copy_props code in an internal function
#
# This will allow a later patch to add an extra parameter to control the
# copying of side data.
? That would make it easier to spot possible mistakes in the second patch,
and backtracking changes too.
Regards,
--
Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
