On Sun, Dec 09, 2012 at 02:16:14PM +0000, Måns Rullgård wrote:
> Diego Biurrun <[email protected]> writes:
> > -{"mv4", "use four motion vector by macroblock (mpeg4)", 0,
> > AV_OPT_TYPE_CONST, {.i64 = CODEC_FLAG_4MV }, INT_MIN, INT_MAX, V|E,
> > "flags"},
> > +{"mv4", "use four motion vectors per macroblock (MPEG-4)", 0,
> > AV_OPT_TYPE_CONST, {.i64 = CODEC_FLAG_4MV }, INT_MIN, INT_MAX, V|E,
> > "flags"},
>
> > -{"emu_edge", "don't draw edges", 0, AV_OPT_TYPE_CONST, {.i64 =
> > CODEC_FLAG_EMU_EDGE }, INT_MIN, INT_MAX, 0, "flags"},
> > +{"emu_edge", "do not draw edges", 0, AV_OPT_TYPE_CONST, {.i64 =
> > CODEC_FLAG_EMU_EDGE }, INT_MIN, INT_MAX, 0, "flags"},
>
> > -{"ildct", "use interlaced dct", 0, AV_OPT_TYPE_CONST, {.i64 =
> > CODEC_FLAG_INTERLACED_DCT }, INT_MIN, INT_MAX, V|E, "flags"},
> > +{"ildct", "use interlaced DCT", 0, AV_OPT_TYPE_CONST, {.i64 =
> > CODEC_FLAG_INTERLACED_DCT }, INT_MIN, INT_MAX, V|E, "flags"},
>
> > -{"bitexact", "use only bitexact stuff (except (i)dct)", 0,
> > AV_OPT_TYPE_CONST, {.i64 = CODEC_FLAG_BITEXACT }, INT_MIN, INT_MAX,
> > A|V|S|D|E, "flags"},
> > -{"aic", "h263 advanced intra coding / mpeg4 ac prediction", 0,
> > AV_OPT_TYPE_CONST, {.i64 = CODEC_FLAG_AC_PRED }, INT_MIN, INT_MAX, V|E,
> > "flags"},
> > +{"bitexact", "use only bitexact code (except (I)DCT)", 0,
> > AV_OPT_TYPE_CONST, {.i64 = CODEC_FLAG_BITEXACT }, INT_MIN, INT_MAX,
> > A|V|S|D|E, "flags"},
> > +{"aic", "H.263 advanced intra coding / MPEG-4 ac prediction", 0,
> > AV_OPT_TYPE_CONST, {.i64 = CODEC_FLAG_AC_PRED }, INT_MIN, INT_MAX, V|E,
> > "flags"},
>
> > -{"cgop", "closed gop", 0, AV_OPT_TYPE_CONST, {.i64 = CODEC_FLAG_CLOSED_GOP
> > }, INT_MIN, INT_MAX, V|E, "flags"},
> > +{"cgop", "closed GOP", 0, AV_OPT_TYPE_CONST, {.i64 = CODEC_FLAG_CLOSED_GOP
> > }, INT_MIN, INT_MAX, V|E, "flags"},
>
> These, and plenty others, are style fixes, not typo corrections.
Is that a problem except for amending the log message?
> > -{"qmin", "min video quantizer scale (VBR)", OFFSET(qmin), AV_OPT_TYPE_INT,
> > {.i64 = 2 }, -1, 69, V|E},
> > -{"qmax", "max video quantizer scale (VBR)", OFFSET(qmax), AV_OPT_TYPE_INT,
> > {.i64 = 31 }, -1, 69, V|E},
> > -{"qdiff", "max difference between the quantizer scale (VBR)",
> > OFFSET(max_qdiff), AV_OPT_TYPE_INT, {.i64 = 3 }, INT_MIN, INT_MAX, V|E},
> > +{"qmin", "minimum video quantizer scale (VBR)", OFFSET(qmin),
> > AV_OPT_TYPE_INT, {.i64 = 2 }, -1, 69, V|E},
> > +{"qmax", "maximum video quantizer scale (VBR)", OFFSET(qmax),
> > AV_OPT_TYPE_INT, {.i64 = 31 }, -1, 69, V|E},
> > +{"qdiff", "maximum difference between the quantizer scales (VBR)",
> > OFFSET(max_qdiff), AV_OPT_TYPE_INT, {.i64 = 3 }, INT_MIN, INT_MAX, V|E},
>
> More style changes, replacing min/max with their -imum-suffixed longer
> versions. I'm not sure we want to do this. Help texts should strive to
> be terse, and everybody should understand the abbreviated forms.
There's "-imum" elsewhere in the file. I'm not fond of min/max in
text, as opposed to code. And I don't think these messages threaten
to hit any sort of length limit.
> > --- a/libavutil/log.h
> > +++ b/libavutil/log.h
> > @@ -65,10 +65,11 @@ typedef struct AVClass {
> >
> > /**
> > - * Offset in the structure where a pointer to the parent context for
> > loging is stored.
> > - * for example a decoder that uses eval.c could pass its
> > AVCodecContext to eval as such
> > - * parent context. And a av_log() implementation could then display
> > the parent context
> > - * can be NULL of course
> > + * Offset in the structure where a pointer to the parent context for
> > + * loging is stored. For example a decoder that uses eval.c could pass
> > + * its AVCodecContext to eval as such a parent context. And an av_log()
> > + * implementation could then display the parent context.
> > + * Can be NULL of course.
> > */
>
> This is merely flowing the text differently, not fixing the numerous
> spelling errors within it.
Umm, no. I admittedly missed "loging", but there are three other fixes
in there. Anything else I overlooked?
Will send an updated patch later.
Diego
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
