[FFmpeg-devel] [PATCH] Change option description text to match option name in avcodec/options.c

[Rodney Baker]

On Thu, 3 Jun 2010 22:40:16 M?ns Rullg?rd wrote:
> Rodney Baker <rodney.baker at iinet.net.au> writes:
> > On Thu, 3 Jun 2010 04:10:24 Martin Storsj? wrote:
> >> On Wed, 2 Jun 2010, Rodney Baker wrote:
> >> > $subj
> >> > 
> >> > 
> >> > Index: libavcodec/options.c
> >> > ===================================================================
> >> > --- libavcodec/options.c	(revision 23424)
> >> > +++ libavcodec/options.c	(working copy)
> >> > @@ -160,7 +160,7 @@
> >> > 
> >> >  {"very", "strictly conform to a older more strict version of the spec
> >> >  or reference software", 0, FF_OPT_TYPE_CONST,
> >> >  FF_COMPLIANCE_VERY_STRICT, INT_MIN, INT_MAX, V|D|E, "strict"},
> >> >  {"strict", "strictly conform to all the things in the spec no matter
> >> >  what consequences", 0,
> >> >  FF_OPT_TYPE_CONST, FF_COMPLIANCE_STRICT, INT_MIN, INT_MAX, V|D|E,
> >> >  "strict"}, {"normal", NULL, 0, FF_OPT_TYPE_CONST,
> >> >  FF_COMPLIANCE_NORMAL, INT_MIN, INT_MAX, V|D|E, "strict"},
> >> > 
> >> > -{"inofficial", "allow unofficial extensions", 0, FF_OPT_TYPE_CONST,
> >> > FF_COMPLIANCE_INOFFICIAL, INT_MIN, INT_MAX, V|D|E, "strict"},
> >> > +{"inofficial", "allow inofficial extensions", 0, FF_OPT_TYPE_CONST,
> >> > FF_COMPLIANCE_INOFFICIAL, INT_MIN, INT_MAX, V|D|E, "strict"},
> >> > 
> >> >  {"experimental", "allow non standardized experimental things", 0,
> >> >  FF_OPT_TYPE_CONST, FF_COMPLIANCE_EXPERIMENTAL, INT_MIN, INT_MAX,
> >> >  V|D|E, "strict"}, {"b_qoffset", "qp offset between P and B frames",
> >> >  OFFSET(b_quant_offset), FF_OPT_TYPE_FLOAT, 1.25, -FLT_MAX, FLT_MAX,
> >> >  V|E}, {"er", "set error detection aggressivity",
> >> >  OFFSET(error_recognition), FF_OPT_TYPE_INT, FF_ER_CAREFUL, INT_MIN,
> >> >  INT_MAX, A|V|D, "er"},
> >> 
> >> Wasn't this changed recently (in rev 21473 in January), with the
> >> motivation that unofficial is the correct spelling? The name of the
> >> option was left unchanged in order not to break existing apps using
> >> this parameter name.
> > 
> > I initially thought this too - in fact, I was going to propose a patch to
> > correct the spelling of the option but decided against it for the same
> > reason - too many breakages.
> > 
> > Then I checked Webster's Unabridged Dictionary only to discover that
> > "inofficial" is actually more semantically correct (even though it is
> > rather archaic and seems to have largely fallen from use.
> 
> Yes, both forms are considered correct.  However, in modern usage,
> unofficial far outweighs inofficial.  The options should probably have
> been named "unofficial" to begin with, but it's too late for that now.
> We could of course add an alias, with risk of confusing people
> further.

Or add an alias and then deprecate the archaic spelling at the next major 
version bump? Anyway, like I said, not worth arguing over. 

Can we change the internal references to FF_COMPLIANCE_INOFFICIAL to 
UNOFFICIAL and leave the option spelling as-is, or is that part of the public 
API (I'm still not clear whether ff_* means public or non-public)?

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