Cinelerra is an advanced Linux non-linear video editor. Cinelerra provides a timeline-based editing interface similar to Kdenlive and other non-linear video editors. It also provides a wide range of video effects but only a limited number of ready-made transitions. Many interesting transitions can, however, be created from the functionality in Cinelerra.
This blog post focusses on a very useful feature of Cinelerra, the render farm. These notes are based on Cinelerra 2.2CV on Gentoo.
A render farm enables multiple machines on a network to contribute to video rendering, speeding up this memory- and processor-intensive operation. Cinelerra enables the render farm to be used for both "background rendering" and for rendering of the final video.
Background rendering is a feature of Cinelerra whereby the video is rendered in the background for preview purposes. This is far superior to viewing a preview where frames are skipped to reduce the burden on the CPU (in which case the preview will be jerky and not representative of the final rendered video). The render farm speeds up background rendering significantly. In my own case, using an AMD XP4000 single-core processor for background rendering is, well, like watching paint dry. Since I have another machine with an AMD triple-core processor on the network, this can be pressed into service.
As far as I can tell from the documentation, the render farm needs to be set up so that the output directory of the video rendering is the same on all machines on the render farm (which Cinelerra calls "nodes"). I achieve this by logging on with the same username on the master node and the client node (nfs server and nfs client). Assume that the output of the video rendering is this directory on the machine you are using (the master node):
/home/media_user/videos
then all the machines must have this directory, including the same path. Here is an example of how the NFS share would be mounted on the client node:
192.168.1.95:/home/media_user/videos /home/media_user/videos nfs rw,user 0 0
Obviously with NFS you need to make the usual checks that the video output directory is contained in /etc/exports, that the directory is exported rw (read + write) and that the uid and gid (respectively for the user and user's group) match up.
The render farm also needs to be configured in Cinelerra. Below is a screenshot of my own configuration with some notes on the configuration underneath.
Cinelerra's documentation covers the configuration options fairly well, but there are a few things to watch out for. The option "Output for background rendering" must include the directory and the prefix of the rendered files. In our case, it's not enough to enter "/home/media_user/videos". That would be interpreted by Cinelerra as the directory "/home/media_user" and the prefix for the rendered files as "brender" (with the individual files being named by Cinelerra as brender + number, e.g. brender001035).
I changed the default option for "Frames per background rendering job" to the uppermost value recommended by the documentation, which seems to work fine. I also changed "Frames to preroll background" from 0 to 3. The documentation recommends 0 but I found this failed to work properly on video where I was using the Ken Burns effect (zooming in or out). With a value of 0, the interpolation engine didn't work properly with the rendered video switching between a full size image and the size specified by the x y z projector values.
Cinelerra must be installed on all client machines. The syntax for initiating the daemon is:
cinelerra -d [port number]
In our case this would be:
cinelerra -d 1055
Note the high number used for the port. A port number greater than 400 must be used in Linux if you want the Cinelerra daemon on the client node to be started as a non-root-user. If root is initiating the process, the default note can be used (i.e. cinelerra -d without the port number will default to 400).
Once your Cinelerra installations are set up as described, all background rendering and final video rendering will use the render farm. The best way to check whether the render farm is working is to run some background rendering on an extended section of your video timeline. When you play back the rendered video, Cinelerra will complain about missing frames if the render farm isn't working correctly. You can also check in Settings => Preferences to see whether the framerate is greater than zero for the client node.
In conclusion, the render farm is a great feature of a great piece of open source software.
Did you tried the FoxRenderfarm? Any comments for it? I am currently looking for a cost effective render farm. Thanks.
ReplyDeletePeter, The Cinelerra render farm is the only one I have used (on a home network), sorry I can't help with this
ReplyDeleteForRender is the best helper to get your Render done fast and cheap. 3780GHz top power ready to work on full load for 60$ per hour. It's less then 1,5 cent for 1 GHz per hour. Full time support and good discount's for everyone. render farm
ReplyDeleteThere is
ReplyDelete[-f] [-c configuration] [-d port] [-n nice] [-r batch file] [filenames] in cinelerra
What does it mean -n ?
prioritet ?
According to the documentation on Cinelerra's github site, it is the nice value when running Cinelerra as a render farm client. Nice is a utility which controls the priority of a process. I assume therefore that using -n with a number will raise or lower the priority of the render farm client process.
DeleteThe link to the relevant Cinelerra github page is here: https://github.com/r4mp/cinelerra/blob/master/cinelerra-4.6.mod/po/txt/cin.txt
See here for documentation on nice: http://www.thegeekstuff.com/2013/08/nice-renice-command-examples/?utm_source=tuicool
Hi there, I read your blogs on a regular basis. Your humoristic style is witty, keep it up! Thank You for Providing Such a Unique and valuable information, If you are looking for the best Cheap render farm, then visit vfxfarm.com. I enjoyed this blog post.
ReplyDelete