For most editing workflows, I would try proxies before a blanket HEVC-to-H.264 conversion.

A normal transcode creates a new master-like file. If you choose another delivery codec such as H.264, you are decoding the original and then compressing the image again. Even at a high bitrate, that is another lossy generation unless you use a lossless or visually lossless intermediate. It also creates a second full-resolution media set that can be surprisingly large.

A proxy is intentionally temporary. It can be lower resolution and easier to decode because its purpose is only responsive editing. The project retains the link to the original HEVC media, then uses the originals for final output.

There are cases where a full transcode makes sense — unsupported source format, broken timestamps, a collaborative pipeline standardized around an intermediate codec — but “HEVC feels slow” by itself is usually a proxy/hardware-decoding problem first.

Before generating anything, check whether hardware decode is actually working.

Modern GPUs often have fixed-function video decode blocks. If the source profile is supported and the editor uses that hardware path, a difficult HEVC file can become much easier to play. But support is specific: “my GPU supports HEVC” does not necessarily mean every combination of 10-bit, chroma format, resolution and frame rate is accelerated.

A quick diagnostic is useful. Watch CPU and GPU decode activity while playing the clip. If CPU usage is very high and the video-decode engine is idle, the application may be falling back to software decoding. If hardware decoding is active but the timeline still struggles once you add effects, then the bottleneck may be scaling, color processing, compositing or storage rather than the codec alone.

Only after that test would I decide whether proxies are necessary.

In VSDC, the practical order we recommend is: import the original files, try the hardware decoder, and create proxies only if the timeline is still uncomfortable. The project can then use lightweight proxy media during editing while returning to the original source for the final render.

That approach matters with action-camera footage because the “heavy” source often contains more than HEVC: 4K/5K resolution, high frame rate, 10-bit color, HDR/Log and sometimes telemetry metadata that you may want later. Keeping the untouched camera files as masters avoids throwing away useful information just to improve preview speed.

If you do decide to transcode, do it for a specific workflow reason and keep the originals. Do not delete the camera files because the converted copy appears easier to edit.

There is also a storage-management argument for proxies.

Suppose the original HEVC set is 300 GB. A high-bitrate full-resolution H.264 transcode might become larger than the source, so now you are maintaining two large sets. A proxy set can be much smaller because it only needs enough quality and resolution for editorial decisions.

The key is to make sure your editor treats the files as proxies rather than replacement masters. Test the full path on one clip: edit with the proxy, disable/relink it if necessary, and export a short section. Confirm that the final render is using the original resolution and expected color.

Once that works, scaling the same workflow to hundreds of clips is much safer than improvising a manual rename/relink scheme.