[FFmpeg-devel] [PATCH v2] avcodec/noise_bsf: add expr support

[Gyan Doshi]

On 2021-07-30 09:15, Gyan Doshi wrote:
>
>
> On 2021-07-30 00:00, Andreas Rheinhardt wrote:
>> Gyan Doshi:
>>> ---
>>>   doc/bitstream_filters.texi |  64 ++++++++++++---
>>>   libavcodec/noise_bsf.c     | 161 
>>> +++++++++++++++++++++++++++++++++----
>>>   tests/fate/matroska.mak    |   2 +-
>>>   3 files changed, 199 insertions(+), 28 deletions(-)
>>>
>>> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
>>> index d10842ae47..46e4869f80 100644
>>> --- a/doc/bitstream_filters.texi
>>> +++ b/doc/bitstream_filters.texi
>>> @@ -534,20 +534,62 @@ container. Can be used for fuzzing or testing 
>>> error resilience/concealment.
>>>   Parameters:
>>>   @table @option
>>>   @item amount
>>> -A numeral string, whose value is related to how often output bytes 
>>> will
>>> -be modified. Therefore, values below or equal to 0 are forbidden, and
>>> -the lower the more frequent bytes will be modified, with 1 meaning
>>> -every byte is modified.
>>> - at item dropamount
>>> -A numeral string, whose value is related to how often packets will 
>>> be dropped.
>>> -Therefore, values below or equal to 0 are forbidden, and the lower 
>>> the more
>>> -frequent packets will be dropped, with 1 meaning every packet is 
>>> dropped.
>>> +Accepts an expression whose evaluation per-packet determines how 
>>> often bytes in that
>>> +packet will be modified. A value below 0 will result in a variable 
>>> frequency.
>>> +Default is 0 which results in no modification. However, if neither 
>>> amount or drop is specified,
>>> +amount will be set to @var{-1}. See below for accepted variables.
>>> + at item drop, dropamount
>>> +Accepts an expression evaluated per-packet whose value determines 
>>> whether that packet is dropped.
>>> +Evaluation to a positive value results in the packet being dropped. 
>>> Evaluation to a negative
>>> +value results in a variable chance of it being dropped, roughly 
>>> inverse in proportion to the magnitude
>>> +of the value. Default is 0 which results in no drops. See below for 
>>> accepted variables.
>> Negating the dropamount scale broke all prior usages of it.
>
> Yes, with eval used now, the semantics for positive values was best 
> changed, so I mapped the old usage to negative values.
>
> I've rarely seen this filter used in the wild. The only FATE test that 
> employs it uses it incidentally.
> I'll add a note to the docs noting the legacy use and its remapping.

I've restored dropamount to its historical behaviour in 
b9176dbfb7c209f2adf1f420df74b91df56c1fb3

Regards,
Gyan