On Wed, 8 Mar 2017 20:54:43 +0100 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Wed, Mar 08, 2017 at 07:32:26PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 19:20:15 +0100 > > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 17:11:12 +0100 > > > > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > > > > > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > > > > > On Wed, 8 Mar 2017 15:36:25 +0100 > > > > > > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > > > > > > > > > > > On Wed, Mar 08, 2017 at 01:40:11PM +0100, wm4 wrote: > > > [...] > > > > > > > > > > > > > > > > > > also it may be interresting to disable this check for fuzzing so > > > > > > > side data can be fuzzed in a wider range of cases and any past > > > > > > > testcases that happen to use this can still be used for regression > > > > > > > testing > > > > > > > > > > > > I think what you want is fault injection for memory errors, seems > > > > > > out > > > > > > of scope here. > > > > > > > > > > no, i want fuzzing to continue to fuzz side data, it did so in the > > > > > past and it should continue to do so. > > > > > > > > You can fuzz side data as much as you can fuzz AVFrame or > > > > AVCodecContext. I believe randomly changing in-memory data structures > > > > is referred to as fault injection, not fuzzing. > > > > > > it doesnt really matter what you call it, but it was done and the > > > patch breaks it if theres no option to disable it or something else > > > > Well, you can't do it anymore. Why are you so afraid that a potential > > error source is being eliminated? > > well its rather hidden, harder to test for not eliminated. How is it not eliminated? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
