Difference Between Preview Scaling and Proxy?

Hi,
Is the difference between Proxy and Preview Scaling that Proxy creates a smaller file to work with (temporarily), whereas Preview Scaling creates a smaller (lower resolution, but smoother) video preview to help editing while one is in the process of editing?

I am trying to understand the difference between these two features, as they each seem to me to be different ways of accomplishing the same overall end (a smoother, less jerky video playback) during the process of editing.

Thanks for any replies.

A proxy creates a new smaller file with lower resolution, so that you can work fluently while editing. This creation of proxy is done as a separate step before editing.
Preview scaling happens on the fly, so it put stress on the cpu during editing. If you have a huge input video with big resolution its much better to go for proxy editing as this makes the process much smoother (the preview), whereas it will stress your cpu and hinder your whole editing process when you just go for preview scaling. Preview scaling doesn’t produce a smaller extra file to work with, so you save some time if your system can handle the extra amount of work when scaling down. You will also find tutorials and definitions here when searching for ‘proxy editing’ or ‘preview scaling’ :wink:

1 Like

Thanks very much, RilosVideos.

That was pretty much what I thought, although I did not realize that using preview scaling can place stress on the system if the computer is not up to handling the extra load that Preview Scaling puts on the system. Thankfully, I have not had that experience.

I wanted to ask about this here because I did not know if Shotcut used Proxy and Preview Scaling in the same way that other video editing software uses them, or if each different video editing programme manipulates/uses these features in individual ways, different from other programmes.

Thanks again.

Proxy editing means nearly the same in all common video editors, afaik :slight_smile:
There may be differences in handling or procedure but proxy editing allows for high resolution video editing even with poor hardware, as you use a (much) smaller proxy. Scaling in general means scaling on the fly, during editing. When you use a lot of demanding filters e.g. at the same time, this can lead to stuttering/lagging when watching preview playback.
Both methodes don’t effect the outcome in any way, but proxies can be much smoother to work with.

Thanks, RilosVideos. :slightly_smiling_face:

There are also some advantages to preview scaling - it doesn’t just use more cpu for no gain or it would just not exist: it lowers the processing area for filters that affect images.

For example applying a color grading, saturation, contrast, levels and blur to a 4K video is very CPU intensive, but with preview scaling even though there is some CPU involved to downscale to 360p, the filters will process way faster and you can preview the project in a smooth manner.

Thanks, daniel47.

Do you mean that using Preview Scaling when applying those filters to a 4K video will make the filters process faster than without the Preview Scaling applied, faster than using Proxies, or both?

I mean faster than without the Preview Scaling applied.
Proxies are fastest in any scenario I can think of, they are already lower res so they basically already “did” what the preview scaling is doing (but also much more).

Thanks, Daniel.

Preview Scaling deserves more praise. An example project will make the differences between Proxy and Preview Scaling much easier to see. Assume that each project described below has one video clip on the timeline with one text filter attached to it.

Scenario 1: Nothing fancy

  • Source video is 1080p (no proxy)
  • Timeline video mode is 4K
  • Preview Scaling is off

In this scenario, the video file is decoded at 1080p resolution, which is a fair amount of CPU effort. Then the video is scaled up to the timeline resolution, which is 4K. This is CPU-intensive. Then the text filter is applied at 4K, because the text X/Y coordinates are relative to the timeline resolution. If there are multiple tracks, they are composited at 4K. Lastly, the 4K finished frame is scaled down to whatever the size of the preview player’s window is in the Shotcut interface. So the simplified chain of events looks like this:

  • 1080p decode (medium) →
  • 4K upscale to timeline (slow) →
  • 4K filter processing (slow) →
  • 4K compositing (slow) →
  • downsize to preview window (medium)

In this chain, items 2-4 are probably slower individually than decoding 1080p video, especially if multiple tracks with opacity are involved.

As we are about to see, Proxy speeds up file decoding whereas Preview Scaling speeds up frame processing. The higher the resolution, generally the more benefit Preview Scaling has over Proxy.

Scenario 2: Proxy

  • Source video is 360p (proxy of 1080p source)
  • Timeline video mode is 4K
  • Preview Scaling is off

The chain becomes:

  • 360p decode (fast) →
  • 4K upscale to timeline (slow) →
  • 4K filter processing (slow) →
  • 4K compositing (slow) →
  • downsize to preview window (medium)

Notice that only one link in the chain sped up.

Scenario 3: Preview Scaling

  • Source video is 1080p (no proxy)
  • Timeline video mode is 4K
  • Preview Scaling is 360p

The chain becomes:

  • 1080p decode (medium) →
  • 360p downscale to Preview Scaling resolution (medium fast) →
  • 360p filter processing (fast) →
  • 360p compositing (fast) →
  • probably upscale to preview window (fast)

Notice that four links in the chain sped up.
Also notice that a 360p frame has only 2.7% the number of pixels as a 4K frame.
As in, 97.3% of the CPU effort for frame processing has just been eliminated by using Preview Scaling.
At these resolutions, Preview Scaling reduces CPU usage far more than Proxy alone could do.

Scenario 4: Proxy + Preview Scaling

  • Source video is 360p (proxy of 1080p source)
  • Timeline video mode is 4K
  • Preview Scaling is 360p

This is the golden banana. The chain becomes:

  • 360p decode (fast) →
  • No timeline scaling applied because the proxy and Preview Scaling resolutions match (instant) →
  • 360p filter processing (fast) →
  • 360p compositing (fast) →
  • probably upscale to preview window (fast)

Some takeaway tips:

  • Proxy and Preview Scaling work beautifully together when they are the same resolution. The benefits are squandered a bit if the resolutions do not match.
  • From the menu, changing Settings > Interpolation to Bilinear can speed up the scale-to-preview-window step significantly. Bicubic and Lanczos look better but are much slower. Since resolution is already compromised by proxy, Bilinear usually doesn’t hurt the preview quality much more.
  • The decoding step can be sped up by choosing different input file formats. As in, DNxHR will decode faster than H.265. So there is room to tweak things there, too.
5 Likes

Austin, thanks so much for this.

That was an incredible lesson - and I think I followed almost all of it.

I had been about to ask if (my version of) The Golden Banana could be achieved by using Proxy and Preview Scaling together, and I now understand that is the case if they are the same resolution, and if my inference of your implication is correct, that only a small part of the benefit is squandered if the resolutions do not match, so it is therefore a good idea to use both Proxy and Preview Scaling most of the time.

Can you please give some more examples of what you mean by " * The decoding step can be sped up by choosing different input file formats. As in, DNxHR will decode faster than H.265"?

I understand the literal meaning of that statement, but feel that I need some more examples to know how to apply it in context.

For example, what makes the Export present DNxHR decode faster than H.265? How would I know how to compare other presets to know which is best to use?

Fascinating stuff, but much of this is above my head, although I am trying to learn.

Thanks again.

Yes, that is generally true. But it compounds quickly if there are multiple tracks or transitions, and your editing laptop is a potato.

Sometimes, the input format may be out of your control. For example, if someone used a mirrorless camera to capture video, and the camera insisted on making LongGOP H.265 video, then they’re stuck with that format. They could transcode it with Shotcut’s “Convert to Edit-Friendly” feature to change the format to DNxHR or whatever, but it’s probably not worth the effort. If editing is done on proxies, then conversion is worth even less because the editing phase would rarely use the converted files. Editing would typically use the proxy files (except maybe a full-resolution spot check for any color grading and text alignment).

But sometimes, you will get a chance to take control of the input format. For instance, if someone has old family video that is in an interlaced format and they want to convert it to progressive format for editing, then an opportunity exists to do that conversion directly into a fast format like DNxHR. I’m not saying that’s always the best idea because DNxHR makes huge files that will blow up your archive space. But the option does exist.

It’s mostly about the algorithms used by each format to compress video, followed by how well the codec is implemented for a specific type of processor (x86 vs x64 vs ARM for example). DNxHR, by an intentional design choice, decodes fast by using a relatively simple compression algorithm (simple and few math steps), but that simplicity means not much compression is applied, which is why the files get huge. Meanwhile, H.265 uses a wide array of complex math tricks to achieve a lot of compression. The resulting files are small, but it takes a ton of CPU to undo the math and get the original frame back. These are intentional choices made by the designers of each format. This is why each format specializes in a different stage of the editing workflow. DNxHR is good for editing where speed counts. H.265 is good for final delivery to a customer where small file sizes count (which lowers network bandwidth costs for streaming providers).

Comparing video codecs is one of those fields where somebody can get a Ph.D. in it and still be wrong or surprised half the time. Once they figure it out, the encoding software gets an update which scrambles the results all over again.

Shotcut has a lot of default codec choices. They are good defaults for most purposes. If you have a specialized purpose in mind, you could search the forum for past discussions or ask a new question. Google can bring back a lot of information, too. Experimentation is the real test, but you would need a good background in FFmpeg to set up those tests. So for now, I’d say don’t worry about it until you absolutely need something different.

2 Likes

Thanks for all of that, Austin.

Interestingly (to me, anyway) one of my YT channels will involve me presenting footage I have shot on my mirrorless camera, and another channel will involve stock video footage which (so far, during my experiments) I cannot get a satisfactory export from, in terms of colour (looks fine in Shotcut, but seems to change a lot when exported, despite what I do in Colour Grading).

I have a lot more experimentation to do, and a lot to learn.

Thank you for contributing to my learning.

1 Like

This topic was automatically closed after 90 days. New replies are no longer allowed.