[FFmpeg-devel] [PATCH] avutil: make AVFrameSideData buffers ref-counted.

[Michael Niedermayer]

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 <nfxjfg at googlemail.com> wrote:
> 
> > On Mon, 23 Mar 2015 11:02:30 -0400
> > "Ronald S. Bultje" <rsbultje at gmail.com> wrote:
> >
> > > Hi,
> > >
> > > On Mon, Mar 23, 2015 at 3:41 AM, Nicolas George <george at 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 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150323/73d8f6ec/attachment.asc>