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 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin
signature.asc
Description: PGP signature
_______________________________________________ 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".
