digital cinema workflow under linux – automation


Research published in March, 2012.

This is the continuation of the initial research for a Digital Cinema Workflow on Linux presented here. Summing up the findings of the previous research:

  1. Considering every step involved – space occupied in disk, processing speed for format conversion, Cinelerra render speed and Cinelerra playback performance – we’ll be better off working with proxies;
  2. The proxy that registered the best performance considering both quality and processing time is the JPEG Bilinear at 50% quality;
  3. Contrary to the statements declared at the section “Overall conclusion from the tests”, we can work with the proxies and replace the JPEG for TIF files for a final render, having the best of both worlds (speed and quality). Also, post-production can be done while we are at the final editing steps, allowing photographer and editor to work together, as initially planned. That is done by updating Cinelerra’s XML.

The previous research showed that we have major stand-alone programs that must be connected to form a workflow, as is usual on video editing in Linux. This research shows how we can use automation scripts to achieve that. This releases us to focus on the creative parts of shooting, editing and making movies.

Registering new tests

Before we continue, and to be sure we are following the right direction, a new test was conducted, this time using 61 seconds (1537 frames) in total of video. That includes four 1920×1080@25fps.

The objective of this test was to determine where we can improve our workflow and if as improvement is possible. The benchmarks registered as follows:


Test 1
Conversion: MOV to DNG to JPEG 50%, with full frames at 1920×1080.
Conversion took 12m26s or 12x the total videos’ length time.
The output (MOVs + DNGs + JPG) occupied 3,5GB or 11x the original space.
Cinelerra playbacks the JPG50% at 24~25fps (real time) with X11-XV driver.
Cinelerra renders the 61s of video in about 57s or real time.

Test 2
Conversion: MOV to DNG to JPEG 50%, with frames at 960×544.
Conversion took 7m25s or 7x the total videos’ length time.
The output (MOVs + DNGs + JPG) occupied 3,5GB (same as above*).
Cinelerra playbacks the JPG50% at 24~25fps (same as above).
Cinelerra renders the 61s of video in about 24s or 2x faster than real time.

Test 3
Conversion: MOV to DNG to JPEG 50%, with frames at 640×360.
Conversion took 6m19s or 6x the total videos’ length time.
The output (MOVs + DNGs + JPG) occupied 3,5GB (same as above*).
Cinelerra playbacks the JPG50% at 24~25fps (same as above).
Cinelerra renders the 61s of video in about 12s = 5x faster than real time.

*This shows that the space is mainly occupied by the DNGs; the JPEGs are almost irrelevant. The original videos (four .mov videos) occupy 317,8MB in disk together.

Conclusion from the test

We can drastically improve the workflow by two means:

  1. If the software movie2dng could output JPEGs directly from the original movies (.mov), we wouldn’t need to convert all the files to DNG to start editing. That would not only save space in disk but pre-editing time. It can be roughly estimated that such change could increase performance between 40-60% (this feedback has been provided for the software author, who is working on a new version for movie2dng);
  2. If we shrink the proxies to ½ or 1/3 of the original video size, we’ll shorten the time for the DNG to JPEG conversion and have better render times with Cinelerra. The drawback for this option is that we’ll have to mess around a lot with Cinelerra’s XML, especially to correct keyframes’ positions.

So, we have a new north to follow later. At the moment, we’ll stick to what we have, which is very good already.

Update – August, 2012.

It has been proven possible to shrink the proxies to 1/3 the original resolution and to update Cinelerra’s XML accordingly via scripting, with more than sactisfactory gains. The code has been inserted in the original scripts, so as to easen the steps involved.

The automated workflow, step by step

Now, you may want to have a general idea of the whole process. It was described in the previous research, more specifically, in this image.

Introdutory videos

The two following short videos serve as a perfect introduction to this article, for they illustrate in images what is being exposed here.

Elphel 353 – Gjøa – Test footage for Digital Cinema #1

Resolution: 2064 x 896 (reduced in the video). Lens: Fujinon MA-Z, aperture 1.8.

Elphel 353 – Gjøa – Test footage for Digital Cinema #2

Resolution: 2240 x 976 (reduced in the video). Lens: Fujinon MA-Z, aperture 1.8.

Step 1: Preparing for editing

We’ll start with that image’s initial part summarized below:

As you can see, things got simpler. We have the captured movies. We run a script and we are ready to start editing – the script takes care of the tough part for us. Let’s see how it works.

First, we have all our videos inside a folder. We put the script with them. We also open a terminal and cd into that folder (to run the script from a terminal is optional, but if you are using Linux, then why not use its resources, eh?):

We run the script. You should notice it creates a working folder (in this case, FLORESTA VERMELHA) and divides it into subfolders; on the terminal you can see the output coming from movie2dng; and you can see the processor working all its 8 cores (that blue filling the black in the menu, above the base folder):

After the script is finished, you can see the sizes and the FPS of the videos on the left (in the terminal) and the final structure of the folders on the right.

We are ready to start editing. From this moment on, we’ll focus only on the folder #03, related to Cinelerra’s XML and our editing sources, the .i2l files. As you can see below, our .i2l files point to the JPEG proxies at this moment.

This is an example of a simple edition:

We have our four movies, represented here by our .i2l files. They are recognized as JPEG sequences by Cinelerra and treated as movies, not as stills. Notice we have a colour problem – the image with the glass clearly has a purple tone. If you see the timeline, you’ll see that is the case for other images as well. This happens because our script uses the some automatic and/or camera settings when converting the DNGs to JPEG. In our example, the camera was probably unset properly during recording. But we don’t have to worry about this now, we’ll fix it during post-production.

Once we finish editing, we can save our project at Cinelerra’s XML folder (folder #03) and paste our second script in our base folder. We are ready to go to post-production.

Step 2: Post production

This part can be summarized as follows:

The second script reads our Editor Decisions List (EDL), in this case our Cinelerra XML file. It creates links only the the DNGs we have used and their respective directories inside our folder #04, the Post Production Folder. It also outputs a human-readable list of these files so that we know where we will be during image treatment.

If we peek into our first folder, we’ll see the links to our DNGs. Notice their numbers match the ones from the list. When we open one of them, we have to set UFRaw to save only its reference (ID) file, as we can see on the image below.

The next image shows an example of a touched-up DNG – it is exaggerated, as we’ll clearly see later.

And by the use of another scripts, we can have previews of these sequences. A good, 2-seconds quick preview, with JPEG 100% quality, small frame size and half the FPS can pop up almost immediately. We can alter the settings to show larger sizes, have longer duration or full FPS, with processing times shifting accordingly.

The image below shows MPlayer’s size during preview, but you must bear in mind that the playback is fullscreen by default – once you run the script, the video will be fullscreen. The only reason we removed that function for the image you see is to have a didactic exhibition of proportions.

Once finished working with one of many DNG sequences, we are ready to go to the next step, which can be seen here.

This part consists basically of processing the DNGs into TIFs and updating Cinelerra’s XML to reflect that update. In the image below, you can see we have our Cinelerra XML in its folder; in a terminal, we are running our fourth script, that shows the folder it is working on – also, notice the processor being used at 100%.

As you can see if you open folder #02, the JPEG files are now sided with TIF files.

The next image shows the end of the script execution. You can see it gives detailed output as to what work has been done, what still must be done and what must be checked. It also informs you for what image sequences Cinelerra’s XML has been updated and created an intermediate XML for you to work with.

Next, we open Cinelerra with the new XML to see the changes. Things to notice: in our folders, inside the im2list directory, we see we have a new .i2l file, with “_post” appended to its original name. That file has been replaced in our Cinelerra project (at the Resources site). If we check the info for it, we’ll also see it is now a TIF Sequence, rather than our original JPEG sequence. It also gets clearer how we exaggerated our touch-ups during the UFRaw phase.

We are almost done. The next image shows the script output once we have finished working with all the DNG sequences. There is also a new Cinelerra XML file, to be used for final render.

That’s it. The last screenshot shows the final XML being opened by Cinelerra. Notice how the colours of the video have changed and have no colour cast. We can also see the changes to our img2list folder, on the bottom right.

Back to the main linux page.


Written by qazav_szaszak

5 de março de 2012 às 16:02

%d blogueiros gostam disto: