> 在 2021年4月22日，下午6:53，Michael Niedermayer <mich...@niedermayer.cc> 写道： > > On Thu, Apr 22, 2021 at 04:13:56PM +0800, Heng Zhang wrote: >> >> >>> 在 2021年4月20日，下午7:12，Michael Niedermayer <mich...@niedermayer.cc> 写道： >>> >>> On Tue, Apr 20, 2021 at 12:34:13PM +0800, Heng Zhang wrote: >>>> >>>> >>>>> 在 2021年4月19日，下午5:47，Michael Niedermayer <mich...@niedermayer.cc> 写道： >>>>> >>>>> On Mon, Apr 19, 2021 at 05:06:10PM +0800, a397341...@163.com >>>>> <mailto:a397341...@163.com> wrote: >>>>>> From: toseven <byone.h...@gmail.com> >>> [...] >>>>>> + if (ret < 0) >>>>>> + { >>>>>> + fprintf(stderr, "Error occurred in av_packet_add_side_data: >>>>>> %s\n", >>>>>> + av_err2str(ret)); >>>>>> + } >>>>>> + return ret; >>>>> >>>>> the { } placing style mismatches whats used in FFmpeg (i dont mind but >>>>> some people do mind) >>>>> >>>>> more general, how much code coverage is gained with these 2 fuzzers >>>>> compared to what already exists ? >>>>> >>>>> thanks >>>> >>>> Okay, I will modify my style to adopt for FFmpeg. What is more, I didn’t >>>> compare the code coverage between them. Do I have to do this? I mainly >>>> refer to the fate test from libavcodec/tests/avpacket.c and >>>> libavfilter/tests/formats.c. >>> >>> If code coverage does not improve, what would be the reason for FFmpeg to >>> include the code ? >> >> Thank your reply. >> My fuzzing targets call the new API interfaces, which are not used by the >> existing fuzzing target. Though I don’t do the related experiment, code >> coverage should improve. > > Current fuzzer coverage can be seen here: > https://storage.googleapis.com/oss-fuzz-coverage/ffmpeg/reports/20210420/linux/src/ffmpeg/report.html > > <https://storage.googleapis.com/oss-fuzz-coverage/ffmpeg/reports/20210420/linux/src/ffmpeg/report.html> > > You are adding 2 targets > target_avpacket_fuzzer: > this calls > av_packet_side_data_name, av_packet_add_side_data, av_packet_free, > av_packet_clone, av_grow_packet, av_new_packet, av_packet_from_data, > From these all but av_packet_clone and av_packet_side_data_name are covered > already > av_packet_side_data_name() is called with a fixed argument in your code > > target_formats_fuzzer: > this calls av_get_channel_layout_string, ff_parse_channel_layout > the first is already covered the second is in libavfilter > libavfilter needs to be fuzzed, such fuzzing would involve building > filter chains or networks based on fuzzer input. > A 2nd set of libavfilter fuzzers should similar to libavcodec fuzzers > generate 1 fuzzer generically for each avfilter similarly to how decoders > from libavcodec are fuzzed. > Such libavfilter fuzzers would then also test most functions within > libavfilter > > More generally about coverage. > If you where in my position what would you want for additional fuzzers ? > maximally increased coverage with mininmal effort ? > I belive this would be achieved with generic fuzzing of filters similar to how > decoders are fuzzed currently. But thats a bit bigger effort > > I see the gsoc page says connecting 2 fate tests to fuzzing can be used as > qualification task. > For connecting such tests, the fate test and the fuzzer should use shared > code and not duplicate. One way that can work is that the fate test takes > some input and that input is fixed for fate but can change when used for > fuzzing > again, the more coverage we can achieve with as little effort the better. > Basically dont be afraid to submit a small amount of code because in fact > i would be more impressed if you can connect fate test(s) with little code > to the fuzzer than with alot of code. > > Thanks
Thank you for your patient reply. I will carefully consider your comments and submit the code again according to your suggestions. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > While the State exists there can be no freedom; when there is freedom there > will be no State. -- Vladimir Lenin > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel> > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org <mailto:ffmpeg-devel-requ...@ffmpeg.org> with > subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
