On Mon, Mar 23, 2015 at 12:43:15PM -0400, Ronald S. Bultje wrote: > Hi, > > On Mon, Mar 23, 2015 at 12:15 PM, wm4 <nfx...@googlemail.com> wrote: > > > 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. > > > I can add non-refcounting for whatever side threshold you come up with. I > don't mind supporting non-refcounted side data (it's trivial). > > > 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
sizeof(AVFrameSideData) is not and should not be part of the ABI so i dont think an application could implement its own av_frame_new_side_data() > > > 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? > > > It's undocumented so I don't know what we want to include as part of > abi/api. We can do this any way you guys want. I just want some side-data > to be ref-counted. > > Ronald > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
