Record the actual media path
Note the package, version, selected decoder and video output. Include the graphics hardware and driver in that setup record. The project describes several hardware backends and their specific filtering limitations. Keep those details with the sample’s media information rather than applying an instruction written for another operating system.
Use a permitted interlaced sample whose characteristics are known. A progressive file is not a suitable proof that deinterlacing works, and a low-quality internet stream can contain problems unrelated to fields. Preserve what is known and label uncertain source metadata explicitly.
Match the setting to the route
QMPlay2 states that hardware decoding can use its own video filtering, so a CPU deinterlacing method may not act in that path. Its current documentation also discusses renderer-specific behaviour, including Vulkan filtering. Read the section matching the actual backend instead of treating one sentence as universal.
Make one supported adjustment and compare the same moving passage. Record whether visible edge artefacts change and whether playback remains stable. Do not simultaneously change the decoder, renderer, output resolution and filter, since the result would not identify which change mattered.
Retain a working baseline
If a comparison does not improve the relevant defect, return to the prior working setup. Keep a simple known sample available so a later driver or player update can be evaluated consistently. A hardware setting should not be forced merely because its name sounds faster.
Send support the platform, package, decoder, renderer, source scan type and exact affected setting. Redact private media paths. This article explains a documented pipeline distinction and a proposed comparison; it does not benchmark decoding speed or claim that one filter is best for every device and programme.