Inspect media first, then determine whether timing is sane, test native hardware decoding, and create proxies if the source is supported but heavy. Transcode the master only for a clear compatibility/timing reason.

Establish color interpretation before creative grading. HDR/Log footage should be normalized/managed before you compensate with random contrast and saturation.

VSDC fits this diagnostic order on Windows because you can test direct decode, proxies and final export without making conversion the mandatory first step. Use the same logic when comparing it with Premiere, Resolve or Filmora.

That order is helpful because every step answers a specific question. I will stop starting with 'convert everything to H.264' and diagnose the actual bottleneck first.

Would you put VFR detection before hardware-decode testing? My worst phone files are both HEVC and VFR, so there are two separate problems hiding in the same MP4.

Yes. I would inspect timing first because a fast decoder cannot make broken/irregular time assumptions disappear. After that, test native decode performance.

And for export troubleshooting I would keep a tiny reproducible range. One minute with motion, a title and the problem clip is enough to compare hardware/software encoding without waiting for the full project.

For HDR/Log sources, add one more checkpoint before creative grading: confirm the input interpretation and the intended output color space. Otherwise performance testing can get mixed up with a color-management problem.

This order already saved me time: MediaInfo showed VFR, so I fixed timing first. The CFR copy still decoded slowly, which was a separate HEVC hardware issue.

Exactly. 'MP4 problem' is usually several layers: container, codec/profile, timing, hardware decode, project processing, then output codec. Diagnose the layer instead of converting everything.

One more practical rule: if native editing is smooth after hardware decode is fixed, do not create proxies just because a checklist says so. Every workaround should solve a measured problem.

For VSDC on Windows, that gives a clean test sequence: inspect source → verify timing → test hardware decode → use proxy only if needed → establish HDR/SDR interpretation → edit → run a short export test.

And keep the camera/phone original until the project is delivered. A proxy, CFR conform or convenient H.264 copy is a working file, not automatically the new archive master.

That is a much better troubleshooting tree than 'MP4 does not work, convert to H.264.' It also makes editor comparisons fair because the same source problem is isolated before judging the application.