Preserve the filter and sample
If a video filter appears ineffective, record the selected filter, QMPlay2 build and exact media. Keep the output and decoder state before changing it. A saved filter preference does not prove that the active playback path actually applies that kind of processing.
Choose a sample where the intended effect can be assessed reliably. For a deinterlacing question, use content whose actual interlaced structure is known rather than assuming all older television footage is interlaced. Keep the original media unchanged during the comparison.
Use the documented decoder-priority route
QMPlay2’s README describes enabling hardware decoding through Playback settings by moving the intended decoder higher in the list. It also explains that CPU-filter behavior differs under hardware decoding. Inspect the actual selected route before repeatedly increasing a CPU filter setting.
Record the starting priority and output. Change only the relevant selection and reopen the same sample as required by the installed build. Do not combine decoder, renderer and several filter changes into a single unexplained experiment.
Compare the actual effect and workload
Observe the same motion passage before and after the deliberate change. Record whether the filter’s expected effect appears and whether playback remains usable. A visible difference is more useful than a checkbox alone, while a resource graph by itself does not show that the correct processing occurred.
If the hardware path provides its own relevant filter control, consult the current project documentation for that actual decoder and renderer. Avoid transferring a setting from another GPU API or operating system as though all hardware paths expose identical processing.
Retain the justified path
Keep the configuration that fits the real sample and task, then check an ordinary reference video. A forced special-purpose filter can be inappropriate for unrelated material. Restore the initial state if the comparison does not justify the change.
The expected outcome is an understood processing route and a reproducible sample. It does not certify every hardware decoder, create source detail or prove that an internet-service failure is a video-filter issue. Retain the build, decoder, output and actual observed effect together.
Questions answered
Does a selected CPU filter prove it is active under hardware decoding?
No. Check the project’s documented path interaction and assess the same sample through the actual route.
Why keep decoder and renderer changes separate?
They can affect processing independently. One change at a time makes the result attributable.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.