On Sun, Jul 03, 2011 at 16:40:38 (CEST), Diego Biurrun wrote:
> On Sun, Jul 03, 2011 at 11:41:24AM +0200, Reinhard Tartler wrote:
>> On Sat, Jul 02, 2011 at 14:50:44 (CEST), Diego Biurrun wrote:
>>
>> > --- a/libavcodec/lpc.c
>> > +++ b/libavcodec/lpc.c
>> > @@ -149,7 +149,7 @@ static int estimate_best_order(double *ref, int
>> > min_order, int max_order)
>> > /**
>> > * Calculate LPC coefficients for multiple orders
>> > *
>> > - * @param use_lpc LPC method for determining coefficients
>> > + * @param lpc_type LPC method for determining coefficients
>> > * 0 = LPC with fixed pre-defined coeffs
>> > * 1 = LPC with coeffs determined by Levinson-Durbin recursion
>> > * 2+ = LPC with coeffs determined by Cholesky factorization using
>> > (use_lpc-1) passes.
>>
>> Not completely wrong, but probably this should rather refer to the
>> documentation of FFLPCType, which documents the enum much better.
>
> How?
Try something like "See #FFLPCType for details" or similar.
>> TBH, I'd rather remove the line, as the enum is already properly
>> linkified at least in the html output.
>
> That would add another warning...
maybe we can turn them off in Doxyfile, then.
>> > --- a/libavcodec/vp8.c
>> > +++ b/libavcodec/vp8.c
>> > @@ -1036,7 +1036,7 @@ static const uint8_t subpel_idx[3][8] = {
>> > *
>> > * @param s VP8 decoding context
>> > * @param dst target buffer for block data at block position
>> > - * @param src reference picture buffer at origin (0, 0)
>> > + * @param ref reference picture buffer at origin (0, 0)
>> > * @param mv motion vector (relative to block position) to get pixel data
>> > from
>> > * @param x_off horizontal position of block from origin (0, 0)
>> > * @param y_off vertical position of block from origin (0, 0)
>>
>> okay, but as indicated in the comment before, AFAIUI this doxy block
>> should be duplicated to vp8_mc_chroma as well.
>
> Done.
>
>> > --- a/libavfilter/graphparser.c
>> > +++ b/libavfilter/graphparser.c
>> > @@ -83,8 +83,8 @@ static char *parse_link_name(const char **buf, AVClass
>> > *log_ctx)
>> > * Create an instance of a filter, initialize and insert it in the
>> > * filtergraph in *ctx.
>> > *
>> > + * @param filt_ctx put here a filter context in case of successful
>> > creation and configuration, NULL otherwise.
>> > * @param ctx the filtergraph context
>> > - * @param put here a filter context in case of successful creation and
>> > configuration, NULL otherwise.
>> > * @param index an index which is supposed to be unique for each filter
>> > instance added to the filtergraph
>> > * @param filt_name the name of the filter to create
>> > * @param args the arguments provided to the filter during its
>> > initialization
>>
>> Err, uh? I had to read the documentation string several times and still
>> don't get it. Does a filt_ctx get created if NULL is passed? The
>> function looks like an constructor to me, so in what cases wouldn't the
>> user want to pass NULL here?
>
> Yes, the doxy could be improved, but I consider this out of the scope
> of this patch.
bad/wrong documentation is worse than no documentation, imo
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel