On Mon, Feb 05, 2018 at 02:20:46PM +, Gaullier Nicolas wrote:
> >this breaks fate
> >
> >If the changes are intended the reference must be updated by the patch
> >causing the changes
>
> Sorry, forgot... Now, I have some questions regarding fate tests:
>
> 1) I would like to update the fate test itself :
> Currently, we have : silencedetect=d=-20dB
> I am considering changing it to : silencedetect=n=-30dB:d=.4
> The reason is that the usage would be more relevant (dB applying to noise +
> duration set to a consistent value for this speech sample), easier to check
> manually in a waveform editor, and that the coverage would be extended for
> the new patches (silence_start=0 + log of silence_end at end of stream).
> Should I first publish the patch with only the fate results changed and later
> on another patch to update the fate test with results changed again ?
> Personally, I would say a single patch with all three items (patch + fate
> test update + fate result update) would be clearer, but I am not familiar
> with ffmpeg usages, so I prefer asking...
>
> 2) I just realized today that I could fix the accuracy of silence_end too,
> even if it is clearly much less important compared to silence_start
> Do you think this should be handled by another patch, or should I better
> group this patch with this one as they both deal with time accuracy and
> affect fate results (I would rather go for the latter) ?
each independant change should be in a seperate patch
>
> 3) Should I prepare a new fate test to cover the new "mono" mode (patch 1/4) ?
if you like, yes
more complete test coverage is always good
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel