Diego Biurrun <[email protected]> writes:

>> > -{"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.

Yet you left some min/max instances unchanged.

>> >      /**
>> > -     * 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?

The sentence break before "and an av_log..." is wrong.  More broadly
speaking, the reference to eval.c is out of place (the name of the C
file being an implementation detail of no relevance to the API), and
the final sentence rings oddly.

-- 
Måns Rullgård
[email protected]
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to