The RED R3D codec is high demanding in terms of processing resources, these are some recommendations to work with this format.
Codecs->RED->GPU decoder type:
This is the most important setting. Since v8.10 the fastest decoder type is the "Cudanew" (up to several times faster than the others when using a high end NVidia GPU). This decoder requires an NVidia board with more than 3GB of memory. (Also check that you have the latest GPU drivers).
Note: If your GPU model does not properly support the selected R3D decoder then you will experience either missing media (chequerboard or black frames) or either a slow speed due to the RED decoder doing a failback to CPU mode (this is not under control of Mistika, so no warning is shown about it, although you can see some feedback from the RED SDK by launching Mistika in a console and looking at the text output. Also, if you see that the CPU activity is high it means that the RED decoder has failback to CPU mode).
- In general, set Performance->Pipe Units and Performance->IO Threads to the numbers of CPU threads of your system, with a maximum of 23 (higher values than 24 or so do will rarely improve speed significantly, and they will increase latency and RAM usage and can create other problems).
But a high setting is not neccesary for the specific case of Cudanew decoder, only for the other decoder types. If you use Cudanew you may want to decrease this value, mainly to improve Play/Stop latency.
Note: A value of 0 is also a good value to start with, as it means auto-configuration (which will use the above recommended values).
- Set mConfig->Codecs->RED->ReduceFactor to a value that permits to work in realtime in your system. The default is 2 (1:2 factor) but depending on the codec variant and the system hardware you may need to set this value to 4 or even 8. The purpose of the reduce factor is to permit much faster speed by asking the codec to decode at smaller resolutions by default, while you are preparing the Timeline and doing previews. Please note that the value that you set in here is just the default value used by the R3DParams effect (while its parameter ReduceFactor = mConfig). But you can easily change it later to highest 1:1 quality (as explained in next point).
The idea here is to use fast decoding for interactive speed and playbacks, and later set R3DParams->Options->Reduce Factor to 1:1 for the final render or when you need top quality.
In many cases 1:2 can be enough even for the final render. For example if your master is HD , decoding at 8K 1:1 is usually a waste of resources.
In the Timeline, apply R3DParams effects to all your R3D clips. This effect controls the image extraction from the camera raw codec. When you need to go back and forth between 1:1 and other reduce factors there is an easy way to change the Reduce factor to all the R3DParam effects in the timeline at the same time. You can do this with the VisualEditor->Propagate function (make the change in one of the R3DParams effects, select the reduce factor parameter, and press Propagate->All)
Tips & Tricks for additional interactivity
The Mistika interface also provides some tricks for additional interactivity in complex situations:
- Press shift while moving the monitor head will mute evaluation until shift key is released
- For permanent mute during long periods, press the V button (mute video).
- Set RecordMonitor->Menu.>Resolution to Dynamic mode, it will show full resolution on pause, but half resolution while doing playbacks. You will also find the same button in the VisualEditor
- The Edit->Setup->MuteMovingClips will mute the evaluation while dragging clips over the Timeline
Full resolution proxies and multilayer groups.
If the above techniques are not enough, then you can use this technique to create full resolution proxies:
For the R3D codec it does not make sense to pre-render low resolution proxies because you can always create them on the fly (by changing the reduce factor as explained above). Please note that for this technique you will not use the "Proxy" mode of the render panel at all (that one is low resolution and rarely used nowadays). Instead, this workflow is based on rendering full resolution proxy versions, just the same images but in a faster format.
A full resolution render to a fast format will provide full quality and also realtime performance. In principle the main disadvantage is that you can not change the camera extraction settings on the proxy version without rendering it again (mainly the color science related settings of the raw codec, so try to get this right before the render). But the Mistika multilayer groups provide a fast way to switch between the raw codec and the full resolution proxy, so you can always go back to the raw coded if needed. To do that, the multilayer workflow is as follows:
1 - Apply R3DParams to all your r3d clips, and let the reduce factor still at low quality for interactivity and realtime (1:2, 1:4, or 1:8 ). Try to do the most part of the conform at this stage to discard unused shots. This is to avoid rendering full resolution proxies for clips that are not really necessary, as those renders will be slow.
2 - Creation of full resolution proxies: Now set reduce factor to what you consider full quality for your project ( 1:1 or 1:2), and use VisualEditor->Propagate->All to switch all R3DParams to that setting. Then select all your clips, and render them in Split to segments mode (which permits to create one render per clip, You also have options to keep same names and timecodes as the originals).
For this render chose a codec that you can easily playback in your systems. If your storage is fast enough then use Mistika .js codec. It is normally the fastest one and it is high quality (uncompressed), and it can match whatever master format (or reference monitor) you want, either YUV or RGB, 422 or 444, and 10 bit or even HDR 16bit ), so once you have the proxy clips in this format you will probably not need to use the raw R3D originals anymore.
Note: Regarding the proxy format, the Mistika .js format is ideal but it requires a fast storage (as it is uncompressed). If your storage is not fast enough for Mistika .js then you can use Prores (it is realtime in almost any decent storage, although it compress images so you may need to switch back to the R3D source more often and also for the final render). Another good option is EXR DWA, which is quality lossless and very appropriated for collaborating with VFX applications, although it requires more CPU resources to work in realtime.
3- After the render you will find the proxy versions on top of the R3D clips. Now select all those clips in all tracks and create their groups them Edit->Macros->Group Segments. This function will create one group per segment, with both the R3D original and the proxy clip inside the group.
4- Each of these groups contains two independent layers ( as there is no effect connecting the rendered clip to the rest of the stack). In these cases, the group will only export the upper layer by default. But there is a handy tool to decide which layer you want use: When you want to switch between the raw version and the rendered proxy, select the affected groups and use Edit->Groups->UseLayer (options).
Please note that if for some reason you need to change the R3Dparams image extraction of any shot its rendered proxy will become obsolete, so you will want to render that proxy again. This workflow is mainly useful when this does not happen too often, which is the normal case.