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


If using an NVidia board, make sure to install the latest NVidia drivers. Otherwise Cuda-new may fail with similar symptoms (checkerboard images) or it can failover to other decoding modes.


Cudanew is is only supported on Linux and Windows (at the date of this document Apple has not announced support for Cuda decoding).


Cudanew requires a modern NVidia board with more than 3GB of graphics memory (but 8 GB or more are highly recommended) . 


Configuration instructions:


An important parameter is the Mistika Config -> Codecs -> RED -> GPU frames.  For Cuda-new we recommend a value of 1, expect for very modern NVidia boards with a lot of GPU memory, which can use a value of 2 for faster performance (but decrease this value to 1 if you observe decoding failures).    Please note that the older GPU decoding modes (Cuda Old / OpenCl) require less memory and can still use a value of 3, but more than 2 is not recommended for the Cudanew (using 3 will not provide significant benefits and it will use a lot of memory that is better to leave available for other effects )


The other important parameter to adjust is the Mistika Config -> Codecs -> RED -> GPU memory. If it is too low the GPU will need to do more swapping with system RAM, thus reducing the performance. If it is too high there will not be added benefits and you may waste graphics memory that could me more useful for other Mistika effects. Logically it also depends on the Timeline content, so may need to experiment to find the optimal values for your project.


Please note that the exact performance gains by using Cudanew will depend on each system, as the previous decoding modes required a lot of CPU. PCs with average CPUs  may experience typical speed gains between x2 and x4  when using Cudanew, while for the case of top class dual Xeon workstations the difference may be much smaller, as they were already very fast thanks to the high amount of CPU cores.  However, even in these cases the interactivity gain in still mode should be very noticeable with the Cudanew mode,  and there is also the advantage that the CPUs will be free for other tasks (like transcoding to CPU intensive codecs). So it is recommended to select Cudanew by default.


Note: If you do not experience any speed gain with the new mode it may be that the RED decoder is doing a failover to other decoding modes. If you see a high CPU usage that is what is happening, as Cudanew only use low CPU resources. If that is the case please check that you hvae the latest  NVidia driver,  and that your GPU model matches the minimum specs specified by RED.



mConfig->Performance settings:


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


FX->R3Dparams->Settings->ReduceFactor


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.