[FFmpeg-devel] [PATCH] Change all instances of "inofficial" to "unofficial" (except c/l option in lavc/options.c)

[Rodney Baker]

On Wed, 16 Jun 2010 02:36:48 Michael Niedermayer wrote:
> On Wed, Jun 16, 2010 at 01:40:32AM +0930, Rodney Baker wrote:
> > $Subj.
> > 
> > I have run "make test" with these patches and all passed.
> > 
> >  avcodec.h |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > 226bef42ac8a7e04f014245c643db52ef55356ab  libavcodec-h.diff-20100616
> > Index: libavcodec/avcodec.h
> > ===================================================================
> > --- libavcodec/avcodec.h	(revision 23615)
> > +++ libavcodec/avcodec.h	(working copy)
> > @@ -1353,7 +1353,7 @@
> > 
> >       * generally do stupid things, whereas setting it to inofficial or
> >       lower * will mean the encoder might produce output that is not
> >       supported by all * spec-compliant decoders. Decoders don't
> >       differentiate between normal,
> > 
> > -     * inofficial and experimental (that is, they always try to decode
> > things +     * unofficial and experimental (that is, they always try to
> > decode things
> > 
> >       * when they can) unless they are explicitly asked to behave
> >       stupidly * (=strictly conform to the specs)
> >       */
> > 
> > @@ -1361,7 +1361,7 @@
> > 
> >  #define FF_COMPLIANCE_VERY_STRICT   2 ///< Strictly conform to an older
> >  more strict version of the spec or reference software. #define
> >  FF_COMPLIANCE_STRICT        1 ///< Strictly conform to all the things
> >  in the spec no matter what consequences. #define FF_COMPLIANCE_NORMAL  
> >       0
> > 
> > -#define FF_COMPLIANCE_INOFFICIAL   -1 ///< Allow inofficial extensions.
> > +#define FF_COMPLIANCE_UNOFFICIAL   -1 ///< Allow unofficial extensions.
> > 
> >  #define FF_COMPLIANCE_EXPERIMENTAL -2 ///< Allow nonstandardized
> >  experimental things.
> 
> breaks API
> 
> [...]

Is it OK to do this at the next major version bump, then, or not? 

(i.e. #if LIBAVCODEC_MAJOR_VERSION < 53 ...)

Forgive my ignorance - are FF_ prefixed items part of the public API or only 
internal API? Could someone please explain this in very simple terms to a 
beginner (so I don't make the same mistake again) or at least point me to the 
right place in the documentation to understand it? 

Thanks for your patience.

-- 
===================================================
Rodney Baker VK5ZTV
rodney.baker at iinet.net.au
===================================================