Hi Tanishk On Tue, Mar 31, 2026 at 04:57:47PM +0530, Tanishk Raj via ffmpeg-devel wrote: > Hi, > > My name is Tanishk Raj, a second-year IT student from MAIT, Delhi. I have > applied to the FFmpeg GSoC project on improving FATE coverage. > > I have started exploring the coverage report and analyzed low-coverage > areas such as libavutil/file_open.c, where branch coverage is relatively > low and error-handling paths appear under-tested. > > I am currently setting up the development environment and plan to begin > working on the qualification task by selecting low-coverage files across > different libraries and improving their test coverage. > > I would appreciate any guidance on: > > - selecting suitable files for initial contributions
Your proposal talks about libavutil/file_open.c if you want, you can use that as part of your qualification task > - best practices for writing FATE tests This is a good question, so just trying to awnser this ad-hoc i would say (and others can add to this) * They must be portable to every platform we support (or be disabled) * when tests cover code using floats and rounding there is the possibility that the output is not bit by bit identical between platforms. So code with floats require some extra care. For some tests the output is genuinely the same on every platform even though it involves floats, and in that case nothing special is needed, they can just be treated like any other bit exact test. But if theres a difference then you need to use some refernce and compare against it or you can sometimes just use integer output and that happens then to be bit by bit identical even though there was a float prior or sometimes you can slighty adjust the input to avoid anything being too close to 0.5 and rounding in opposit directions. Generally floats can be a bit annoying. * Always factor and reuse code, because for example with 500 decoders we would not want to have 500 this_decoder_test.c that would be unmaintainable * If you can excercise a feature by simply encoding (with specific parameters) and decoding it afterwards both just by using ffmpeg CLI then thats a good solution. The decoded output is compared to the encoder input so the whole path is naturally checked. * Make sure the tests genuinely test what they are supposed to, lets say muxing specific metadata then demuxing it with CLI is fine but then for example the demuxer side should print the metadata and it should be in the fate reference file so its checked. > - common mistakes to avoid while submitting patches If you submit a pull request to code.ffmpeg.org 1. make sure your mentor is listed as reviewer or elsewhere on the PR so he knows about it 2. if CI fails build or tests, fix it, dont wait for someone to tell you to fix it (small note, on your first submission CI will not run, it needs to be approved first from an admin) 3. look at our patch submisison checklist (it contains many good ideas but some lines are centered around mail which doesnt apply for code.ffmpeg.org) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Direct Democracy is when the decissions are made by the People, most of whom have no interrest, no time and incomplete understanding of a choice while being bombarded with misleading information. Representative Democracy is when you are handed 2 dice and can choose which to roll.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
