[FFmpeg-devel] [PATCH 1/8] Deprecate avcodec_get_pix_fmt_name() in favor of the new av_get_pix_fmt_name().

[Tomas Härdin]

On Mon, 2010-11-08 at 13:39 +0100, Stefano Sabatini wrote:
> On date Monday 2010-11-08 13:23:53 +0100, Tomas H?rdin encoded:
> > On Sun, 2010-11-07 at 15:06 +0100, Michael Niedermayer wrote:
> > > On Sun, Nov 07, 2010 at 11:37:54AM +0100, Stefano Sabatini wrote:
> > > > On date Sunday 2010-11-07 00:57:08 +0100, Michael Niedermayer encoded:
> > > > > On Sat, Nov 06, 2010 at 02:12:43PM +0100, Stefano Sabatini wrote:
> > > > > > On date Saturday 2010-11-06 03:07:13 +0100, Michael Niedermayer encoded:
> > > > > > > On Fri, Nov 05, 2010 at 12:00:32PM +0100, Stefano Sabatini wrote:
> > > > > > > > Consistent with av_get_sample_fmt_name().
> > > > > > [...]
> > > > > > > > --- a/libavutil/pixdesc.c
> > > > > > > > +++ b/libavutil/pixdesc.c
> > > > > > > > @@ -814,6 +814,14 @@ static enum PixelFormat get_pix_fmt_internal(const char *name)
> > > > > > > >      return PIX_FMT_NONE;
> > > > > > > >  }
> > > > > > > >  
> > > > > > > > +const char *av_get_pix_fmt_name(enum PixelFormat pix_fmt)
> > > > > > > > +{
> > > > > > > > +    if (pix_fmt < 0 || pix_fmt >= PIX_FMT_NB)
> > > > > > > > +        return NULL;
> > > > > > > > +    else
> > > > > > > > +        return av_pix_fmt_descriptors[pix_fmt].name;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > 
> > > > > > > iam against adding a function per field of a public structure.
> > > > > > 
> > > > > > Consistent with av_get_sample_fmt_name() so the user will expect to
> > > > > 
> > > > > The sample formats are desribed in a private struct, the pixel formats
> > > > 
> > > > I know all this, and I repeat what I already said,
> > > > av_pix_fmt_descriptors[pix_fmt].name is an awkward way for getting the
> > > > name of a pixel format and less safe (no check on pix_fmt range),
> > > 
> > > as said then add a function to get the descriptor
> > > adding a function that gets 1 field from a descriptor is perverse
> > > That field has no special meaning compared to other fields and our API is
> > > complex enough as it is. And we surely dont want to have a function for each
> > > field.
> > 
> > +1
> > 
> > This also allows Windows users to access those fields. See a thread a
> > while back regarding that.
> 
> Yes and I remember it got stucked for some reason (and help in this
> area is welcome, that is don't expect a patch from me).

Basically what needs to be done for that is have the import libraries
also export global variables and not just the functions, thus exposing
the entire API. That or add getter functions for all global variables
(basically make our own stubs).

I tried solving it with some ifdef trickery in the headers, but M?ns
pointed out that it's possible to compile both static and dynamic
libraries at the same time. That is, the build system can't know how the
user intends to link with the libraries.

/Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101108/383c64cd/attachment.pgp>