[FFmpeg-devel] [PATCH] vf_unsharp: extend/improve feedback for validity checks

Stefano Sabatini stefano.sabatini-lala at poste.it
Sun Aug 14 16:48:20 CEST 2011


On date Sunday 2011-08-14 14:42:04 +0200, Michael Niedermayer encoded:
> On Sat, Aug 13, 2011 at 01:29:25AM +0200, Stefano Sabatini wrote:
> > On date Saturday 2011-08-13 01:11:49 +0200, Stefano Sabatini encoded:
> > > Abort for invalid too big values, and exactly state why the input
> > > value is invalid.
> > > 
> > > In particular, avoid out-of-buffer access with too big values.
> > > ---
> > >  libavfilter/vf_unsharp.c |   20 ++++++++++++++------
> > >  1 files changed, 14 insertions(+), 6 deletions(-)
> > 
> > Regarding the syntax, the mp=unsharp filter supports a format of the
> > kind:
> > [lc]XxY:AMOUNT
> > 
> > while unsharp supports only (awkward) positional parameters.
> > 
> > A better mixed solution would be to implement a syntax of the kind:
> > [lc]=XxY+AMOUNT
> > 
> > for example:
> > l=5x5+0.3:c=3x3-2.0
> > 
> > while back-supporting the old syntax.
> 

> the old code also seems to support l1:2 as a shorthand of l1x1:2 from
> looking at the code 

I can easily port this (undocumented) feature.

> and iam not sure if using a = is a good idea, that makes
> unsharp=l=5x5+0.3
> and to me the double = looks a bit odd
> but thats just my 2 cent

On the other hand this is how we handle options in other filters
(FILTER=OPT_1=VAL_1:...:OPT_n=VAL_n), and we use ":" as option
separator so I didn't want to make it different just in this case.

Consider also that the mp=unsharp parsing code is not particularly
robust and unambiguous (e.g. mp=unsharp=l31:1c13:1c23:12fooo is
valid).

I could add another backward compatibility syntax layer for the
mp=unsharp syntax, but that would be imo overkill.
-- 
FFmpeg = Freak Fast Maxi Prodigious Eccentric Gangster


More information about the ffmpeg-devel mailing list