Mastodon

Kdenlive Proxy Clips

Kdenlive supports transparently working with so-called proxy clips in the timeline in order to speed up editing and previewing. Proxies are copies of your video media, but reduced in image size and quality as compared to the original clips. So how does the proxy concept work behind the scenes?

Tricking MLT’s Producers

Kdenlive’s (project) bin clips are represented from MLT’s perspective in form of so-called producers. When enabling proxying for the project or a specific video, Kdenlive first renders low-fidelity proxy clips for the video clips in question. Next, Kdenlive simply tells the existing producers to use the new proxy clip media files, instead of the original one. Of course, Kdenlive keeps the original media references. These old references are need in case the whole project is to be rendered or when you switch off proxying again, either for all or only a specific clip.

Ex: Clip Without/With Disabled Proxy

Time for a real-world example, which will better illustrate the tricks Kdenlive plays on its MLT project. Let’s start with a project and examine one of its producers without a proxy:

<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 point 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 by Kdenlive, but ignored by MLT. It maintains the reference to the original clip when the proxy has been swept in; see also below for details.

To drive the point home, only the resource property matters to MLT. As MLT has no notion of proxy clips, it don’t know about Kdenlive fooling it while proxy clips are enabled.

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.

Ex: Clip With Proxy Enabled

Let us now check the same Kdenlive project XML snipped with a proxy clip enabled and created; please pay attention to the properties in bold:

<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.

Wrap-Up

So the general mechanics of proxies are as follows: as MLT has no concept of proxies. Instead, 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.

By the way: 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.