Inside Kdenlive Projects: Proxy Clips

Kdenlive supports transparently working with so-called proxy clips in the timeline to speed up editing and previewing. Proxies are reduced in image size and quality as compared to their original clips. But how does the proxy concept work behind the scenes?


As we've seen in previous posts, bin clips are so-called producers from MLT's perspective. What Kdenlive now does is: it keeps the same producer, but points it either to the original clip, or alternatively to an especially-rendered low-quality proxy clip.

Clip Without/With Disabled Proxy

A real-world example for illustration:

<producer id="3" title="Anonymous Submission" out="302" in="0">
  <property name="resource">Videos/kdenlive/bug hunting/GOPR0479.MP4</property>
  ...
  <property name="kdenlive:proxy">-</property>
  <property name="kdenlive:originalurl">Videos/kdenlive/⇝
    ⇝bug hunting/GOPR0479.MP4</property>
  ...
<producer> 

A normal, non-proxy clip has:

• its resource= property set to the original clip, and this is what matters to MLT;
• optionally a kdenlive:proxy="-" property (a simple dash or minus sign; the ASCII one, but not the Unicode minus),
• and an optional kdenlive:originalurl= property, that also references the original clip. This property is only for use in Kdenlive, and maintains the link to the original clip while the proxy has been swept in; see also below for details.

To MLT, only the resource property matters, as MLT has no notion of proxy clips.

When the optional kdenlive:proxy property is present, then this signals to Kdenlive that there has been a proxy generated for this clip, but the proxy currently is not in use.

Clip With Proxy Enabled

A real-world proxy example for illustration:

<producer id="3" title="Anonymous Submission" out="302" in="0">
  <property name="resource">.cache/kdenlive/proxy/⇝
    ⇝c12edca9c228a284a5752a0852ed0117-640.mov</property>
  <property name="kdenlive:proxy">.cache/kdenlive/proxy/⇝
    ⇝c12edca9c228a284a5752a0852ed0117-640.mov</property>
  <property name="kdenlive:originalurl">Videos/kdenlive/⇝
    ⇝bug hunting/GOPR0013-f1.png</property>
  ...
  <property name="kdenlive:file_hash">⇝
    ⇝c12edca9c228a284a5752a0852ed0117</property>
  ...
<producer> 

A proxied clip has:

• its resource= property set to the proxy clip, as this is the property that matters to MLT. In consequence, MLT now works with the proxy clip.
• the property kdenlive:proxy= is present and its value is not "-", but points to the proxy clip.
• the property kdenlive:originalurl= is present and points to the original source clip.

Now if you look closely at the value of the property kdenlive:file_hash=, and next at the filename of the proxy clip, then you should notice that the proxy filename is actually the file hash of the original clip. Well, almost. In addition, we see a trailing dash, followed by a number that represents the proxy resolution.

So the general proxy filename structure is as follows:

<file_hash>-<resolution>.<ext>

In addition, the proxy path clearly shows that Kdenlive shares proxies between different projects: the proxy cache folder is $HOME/.cache/kdenlive/proxy/. The exact location depends on your XDG cache settings, so it may be different on some systems from what we see here.

Summary

So the general mechanics of proxies are as follows: as MLT has no concept of proxies, Kdenlive changes the source clips of the producers on-the-fly as required. For a proxied clip, Kdenlive sets the producer to point to a proxy clip. When disabling the proxy for such a clip, or for a clip without proxy, Kdenlive tells the producer to use the original clip.

For final rendering, Kdenlive always creates a temporary copy of its timeline for MLT to render. And in this temporary copy, all producers always point to the original clips.

The old render option to render using proxy clips is gone, at least for the recent Kdenlive releases, such as 16.04 and 16.08.