On Mon, 23 Mar 2015 11:02:30 -0400 "Ronald S. Bultje" <rsbul...@gmail.com> wrote:
> 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). Well, you're really coming up with a special-case here. Side-data as designed really just included additional parameters and such, and no bulk data. On the other hand, nothing really speaks against extending AVFrame for refcounted side-data. Maybe very small side-data should not be refcounted, because the refcounting adds at least 2 more malloc allocations per side-data. > 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... Uh, no, this is not how we should do things. You clearly define what's included in ABI and API, and what not. But it seems this question is not easily answered in this case. Did you ask Anton? > I can split the code move also, sure. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
