Hi, On Mon, Mar 23, 2015 at 3:41 AM, Nicolas George <geo...@nsup.org> wrote:
> 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? I asked that on IRC yesterday. The best answer I got was "probably because this data is usually small". Which is true for most fields, but not all (e.g. mvs). Consequences for API users is that people that wrote their own personal av_frame_new_side_data() function are going to be screwed. There's some code in av_ref_frame() to deal with that for image planes (if !buf alloc new mem and memcpy), which we could theoretically do here as well. I'm not sure we care about people messing with our public structures outside the provided api, though... I can split the code move also, sure. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
