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

[Gyan Doshi]

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.

Regards,
Gyan