[FFmpeg-devel] [PATCH 1/3] lavc: implement accessors for some AVFrame fields.
Michael Niedermayer
michaelni at gmx.at
Sun Apr 29 18:48:50 CEST 2012
On Sun, Apr 29, 2012 at 05:57:05PM +0200, Clément Bœsch wrote:
> On Sun, Apr 29, 2012 at 02:47:47PM +0200, Michael Niedermayer wrote:
> > On Sun, Apr 29, 2012 at 12:10:07PM +0200, Clément Bœsch wrote:
> > > On Sun, Apr 29, 2012 at 11:21:44AM +0200, Nicolas George wrote:
> > > > Compared to av_opt_ptr, accessors bring:
> > > >
> > > > - better performance (negligible);
> > > > - compile-time type check;
> > > > - link-time existence check
> > > > (or at worst, a dynamic linker error instead of a NULL dereference).
> > > >
> > >
> > > I like the idea, but by the way, should we make this for all the
> > > user-editable/readable fields, with a doxy associated with them?
> > >
> >
> > > "sometimes there is a getter/setter, sometimes not; how am I supposed to
> > > know if I can change this given field?"
> >
> > all fields are supposed to list this already:
> > > > * - encoding: unused
> > > > * - decoding: read by user.
> > for example
> >
>
> Yes but adding a bunch of getter/setter for a limited range of options
> might be confusing since the API gets inconsistent. Of course it's somehow
> already the case, but in the current state it appears like what it really
> is: a workaround for ABI issues. After the patch it looks more like
> helpers for users. That's the reason I was just raising the idea of
> extending this to every user configurable fields.
indeed, i misunderstood, thanks for clarifying
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120429/4d70fd7c/attachment.asc>
More information about the ffmpeg-devel
mailing list