[FFmpeg-devel] [PATCH] lsws/swscale.h: introduce sws_get_gaussian_vec
Michael Niedermayer
michael at niedermayer.cc
Sat Sep 2 23:07:53 EEST 2023
On Fri, Sep 01, 2023 at 08:38:26PM +0200, Stefano Sabatini wrote:
> On date Friday 2023-09-01 18:54:40 +0200, Michael Niedermayer wrote:
> > On Thu, Aug 31, 2023 at 07:16:20PM +0200, Stefano Sabatini wrote:
> [...]
> > > +/**
> > > + * Compute and return a normalized Gaussian vector.
> > > + *
> > > + * @param vecp: pointer where the computed vector is put in case of
> > > + * success
> > > + * @param standard_deviation the standard deviation used to generate
> > > + * the Gaussian vector, must be a non-negative value
> > > + * @param quality the quality of the generated Gaussian vector, must
> > > + * be a non-negative value. It affects the lenght of the generated
> > > + * vector. A value equal to 3 corresponds to high quality.
> > > + * @param log_ctx a pointer to an arbitrary struct of which the first
> > > + * field is a pointer to an AVClass struct (used for av_log)
> > > + * used for logging, can be NULL
> > > + *
> > > + * @return a negative error code on error, non negative otherwise
> > > + */
> > > +int sws_get_gaussian_vec(SwsVector **vecp,
> > > + double standard_deviation, double quality,
> > > + void *log_ctx);
> >
> > which of the two do you consider better?
> >
> > First, here the central part we return is the vector
> >
> > SwsVector *gaus_vec = sws_getGaussianVec(NULL, 1, 2);
> > SwsVector *temp_vec = sws_ConvolveVec(NULL, in_vec, gaus_vec);
> > sws_averageVec(temp_vec, temp_vec, in_vec);
> >
> > av_free(gaus_vec);
> > return temp_vec; // Error checking here happens by temp_vec being NULL in all cases of error
> >
> > vs.
> >
> > Second, here the central part we return is the error code
> >
> > SwsVector *gaus_vec = NULL;
> > SwsVector *temp_vec = NULL;
> > int err = sws_getGaussianVec(&gaus_vec, 1, 2);
> > if (err<0)
> > goto fail;
> >
> > err = sws_ConvolveVec(&temp_vec, in_vec, gaus_vec);
> > if (err<0)
> > goto fail;
> >
> > err = sws_averageVec(&temp_vec, temp_vec, in_vec);
> > if (err<0)
> > goto fail;
>
> The latter pattern enables differentiation between error codes (ENOMEM
> or EINVAL) and provides feedback in the log message. With the former
> you only know if it fails, but you don't know why (relevant in case
> e.g. we make the parameter tunable by a filter and we don't want to
> add additional validation and logging at the filter level).
can the API be designed so that optionally the user could choose to
only check the error code after several steps ?
(this would avoid the need for 1 check per call where the fine grained
information is not needed)
I mean similar to the concept of NAN in floating point so that a failure
can be propagated and only at the end checked.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20230902/c3c13311/attachment.sig>
More information about the ffmpeg-devel
mailing list