Hi, 2011/8/8 Måns Rullgård <[email protected]>: > "Ronald S. Bultje" <[email protected]> writes: >> On Mon, Aug 8, 2011 at 11:17 AM, Diego Biurrun <[email protected]> wrote: >>> On Mon, Aug 08, 2011 at 11:00:40AM -0700, Ronald S. Bultje wrote: >>>> On Mon, Aug 8, 2011 at 3:30 AM, Diego Biurrun <[email protected]> wrote: >>>> > --- a/libavcodec/truespeech.c >>>> > +++ b/libavcodec/truespeech.c >>>> > @@ -33,13 +33,13 @@ >>>> > */ >>>> > typedef struct { >>>> > /* input data */ >>>> > - int16_t vector[8]; //< input vector: 5/5/4/4/4/3/3/3 >>>> > - int offset1[2]; //< 8-bit value, used in one copying offset >>>> > - int offset2[4]; //< 7-bit value, encodes offsets for copying >>>> > and for two-point filter >>>> > - int pulseoff[4]; //< 4-bit offset of pulse values block >>>> > - int pulsepos[4]; //< 27-bit variable, encodes 7 pulse positions >>>> > - int pulseval[4]; //< 7x2-bit pulse values >>>> > - int flag; //< 1-bit flag, shows how to choose filters >>>> > + int16_t vector[8]; // input vector: 5/5/4/4/4/3/3/3 >>>> > + int offset1[2]; // 8-bit value, used in one copying offset >>>> > + int offset2[4]; // 7-bit value, encodes offsets for copying and >>>> > for two-point filter >>>> > + int pulseoff[4]; // 4-bit offset of pulse values block >>>> > + int pulsepos[4]; // 27-bit variable, encodes 7 pulse positions >>>> > + int pulseval[4]; // 7x2-bit pulse values >>>> > + int flag; // 1-bit flag, shows how to choose filters >>>> > /* temporary data */ >>>> > int filtbuf[146]; // some big vector used for storing filters >>>> > int prevfilt[8]; // filter from previous frame >>>> > --- a/libavcodec/vp3.c >>>> > +++ b/libavcodec/vp3.c >>>> > @@ -225,7 +225,7 @@ typedef struct Vp3DecodeContext { >>>> > /* these arrays need to be on 16-byte boundaries since SSE2 >>>> > operations >>>> > * index into them */ >>>> > - DECLARE_ALIGNED(16, int16_t, qmat)[3][2][3][64]; >>>> > //<qmat[qpi][is_inter][plane] >>>> > + DECLARE_ALIGNED(16, int16_t, qmat)[3][2][3][64]; // >>>> > qmat[qpi][is_inter][plane] >>>> > --- a/libavfilter/vf_drawbox.c >>>> > +++ b/libavfilter/vf_drawbox.c >>>> > @@ -34,7 +34,7 @@ enum { Y, U, V, A }; >>>> > typedef struct { >>>> > int x, y, w, h; >>>> > unsigned char yuv_color[4]; >>>> > - int vsub, hsub; //< chroma subsampling >>>> > + int vsub, hsub; // chroma subsampling >>>> > } DrawBoxContext; >>>> >>>> All these are struct members, are you sure you want to drop their doxy? >>> >>> I see little point in (doxygen) documenting structs only used in a >>> single file and/or documenting only single struct members. But I >>> can surely be convinced of something else... >> >> We do that in many decoders. It helps to document the implementation >> if ever, in the far far future ahead, the original author disappears >> and some poor new soul has to fix bugs or add new features instead. > > Plain comments are good enough for that. Doxygen is mostly intended to > generate documentation for people who otherwise have no reason to read > the code.
The idea is "have documentation open in browser, and look at actual code in editor". Otherwise you need multiple code editors open. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
