Timeouts can happen with various conditions, big, slow to decode files
is one of them. Most of the time those timeouts are not really important
to "fix". While they may show some issues like we currently have with
audio EOF #14427 for ao-null-untimed. Most of the reports are completely
not important and we should focus on other topics.
Ignore the timeouts during file playback, note that this will still
report any timeouts that happen in other conditions.
5 seconds of playback should cover most of interesting mpv code, even
for strange samples.
This will likely be reverted at some point in the future, but let first
stabilize the OSS-Fuzz, without dozens of bogus timeouts.
Loading external files makes little sense. Might disable this completely
later, but let see how it works, The idea is the same as for direct
load. Exclude paths starting with `file://.` and `file:///`. But still
fuzz any processing that other input might have. It shouldn't be a huge
problem if we do `file://mpv` for example. Not great, but also not
terrible.
fuzzer_set_property.c:
fuzz mpv_set_property in both initialized and non-initialized state.
Useful for user provided values sanitization test. I've already seen
some memory leaks in parsing code, good to drill it.
fuzzer_loadfile.c:
mpv_command "loadfile" test. Good for testing demuxers, decoding and
playback loop. Sadly in headless mode we can't really test AO and VO,
but at least all the code around can be fuzzed. Especially our custom
demuxers like demux_mkv.
fuzzer_loadfile_direct.c:
Similar to loadfile above, but instead of saving the data to file, it
passes the fuzz input in the command. Generated protocol specific
versions (mf:// and memory:// for now) and generic one.
Nothing really complex, but good start and even those few targets should
give good coverage of the most common code paths in libmpv.
Kacper Michajłow