[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

3. Configuration

Because of its flexibility, Cinelerra cannot be optimized without special configuration for your specific needs. Unfortunately, very few parameters are adjustable at compile time. Therefore, runtime configuration is the only option for most users because of the multitude of parameters available.
Below are configuration options as well as the supported API’s in GNU/Linux.
In Cinelerra, go to settings->preferences to see the options.


3.1 Environment variables

In UNIX derivatives, environment variables are global variables in the shell which all applications can read. They are set with a command like set VARIABLE=value. All the environment variables can be viewed with a command like env. Cinelerra recognizes the following environment variables:


3.2 Audio drivers

The audio drivers are used for both recording and playback. Their functionality is described below:


3.2.1 Sound driver attributes


3.2.2 OSS

This was the first GNU/Linux sound driver. It had an open source implementation and a commercial implementation with more sound cards supported. It was the standard sound driver up to GNU/Linux 2.4. It still is the only sound driver which an i386 binary can use when running on an x86_64 system.


3.2.3 OSS Envy24

The commercial version of OSS had a variant for 24 bit 96 KHz soundcards. This variant required significant changes to the way the sound drivers were used, hence the need for the new driver.


3.2.4 Alsa

ALSA is the most common sound driver in GNU/Linux 2.6. It supports most of soundcards now. It takes advantage of low latency features in GNU/Linux 2.6 to get better performance than OSS had in 2.4, but roughly the same performance that OSS had in 2.0. Unfortunately ALSA is constantly changing. A program which works with it one day may not the next day. New wrappers are being developed on top of ALSA. We plan to support them at regular intervals, though not at every new release of a new wrapper.
ALSA is no longer portable between i386 and x86_64. If an i386 binary tries to play back on an x86_64 kernel, it will crash. For this scenario, use OSS.


3.2.5 Esound

ESOUND was a sound server that sat on top of OSS. It was written for a window manager called Enlightenment. It supports a limited number of bits and has high latency compared to more modern drivers, but it does have the ability to multiplex multiple audio sources. It is unknown whether it still works.


3.2.6 Raw 1394

The was the first interface between GNU/Linux software and firewire camcorders. It is the least reliable way to play audio to a camcorder and consists of a library on top of the kernel commands.


3.2.7 DV 1394

This is the second rewrite of DV camcorder support in GNU/Linux. This is the most reliable way to play audio to a camcorder and consists of direct kernel commands.


3.2.8 IEC 61883

The third rewrite of DV camcorder support in GNU/Linux. This is a library on top of RAW 1394 which is a library on top of the kernel commands. It is less reliable than DV 1394 but more reliable than RAW 1394. The next rewrite ought to fix that. Visit http://www.linux1394.org for more information and the latest drivers.


3.3 Video drivers

The video drivers are used for video playback in the compositor and the viewer.


3.3.1 Video driver attributes


3.3.2 X11

This was the first method of graphical display on any UNIX system. It just writes the RGB triplet for each pixel directly to the window. It is the slowest playback method. It is still useful as a fallback when graphics hardware can not handle very large frames.


3.3.3 X11-XV

This was an enhancement to X11 in 1999. It converts YUV to RGB in hardware with scaling. It is the preferred playback method but can not handle large frame sizes. The maximum video size for XV is usually 1920x1080.


3.3.4 X11-OpenGL

The most powerful video playback method is OpenGL. With this driver, most effects are done in hardware. OpenGL allows video sizes up to the maximum texture size, which is usually larger than what XV supports, depending on the graphics driver. To enable it you will need a binary built with OpenGL support. The configure option to enable OpenGL is ‘--enable-opengl’. You need a video card which supports OpenGL 2.0. Recent Nvidia video cards should work. You also need to use a video driver supporting OpenGL 2.0, such as Nvidia’s binary driver. To know if your video driver supports OpenGL 2.0, type the following command: glxinfo | grep "OpenGL version"

OpenGL relies on PBuffers and shaders to do video rendering. The graphics driver must support OpenGL 2.0 and Cinelerra needs to be explicitly compiled with OpenGL 2.0 support. This requires compiling it on a system with the OpenGL 2.0 headers. PBuffers are known to be fickle. If the graphics card does not have enough memory or does not have the right visuals, PBuffers will not work. If OpenGL does not work, try seeking several frames or restarting Cinelerra.

Limitations:


3.3.5 Buz

This is a method for playing motion JPEG-A files directly to a composite analog signal. It uses a popular hack of the Video4Linux 1 driver from 2000 to decompress JPEG in hardware. Even though analog output is largely obsolete, newer drivers have replaced BUZ.


3.3.6 Raw 1394 video playback

This was the first interface between GNU/Linux software and firewire camcorders. It is the least reliable way to play video to a camcorder and it consists of a library on top of the kernel commands.


3.3.7 DV 1394 video playback

The second rewrite of DV camcorder support in GNU/Linux. This was the most reliable way to play video to a camcorder and consists of direct kernel commands.


3.3.8 IEC 61883 video playback

The third rewrite of DV camcorder support in GNU/Linux. This is a library on top of RAW 1394 and is less reliable than DV 1394 but more reliable than RAW 1394. The next rewrite ought to fix that. Visit http://www.linux1394.org for more information and the latest drivers.


3.4 Playback


3.4.1 Audio out

These determine what happens when you play sound from the timeline.


3.4.2 Video out

These determine how video gets from the timeline to your eyes.


3.5 Recording

The parameters here expedite the File->Record... function by allowing the user to pre-configure the file format. The file format is applied to all recordings. Also set here is the hardware for recording, since the hardware determines the supported file format (in most cases).


3.5.1 File format

This determines the output file format for recordings. It depends heavily on the type of driver used. The menu selections are the same as the rendering interface. See See section Rendering files. The Record audio tracks toggle must be enabled to record audio. The Record video tracks toggle must be enabled to record video. The wrench button left of each toggle opens a configuration dialog in order to set the compression scheme (codec) for each audio and video output stream. The audio and video is wrapped in a container format defined by the File Format menu. Different wrappers may record audio only, video only, or both.

Some video drivers can only record to a certain container. DV, for example, can only record to Quicktime with DV as the video compression scheme. If the video driver is changed, the file format may be updated to give the supported output. If you change the file format to an unsupported format, it may not work with the video driver.


3.5.2 Audio in

These determine what happens when you record audio.


3.5.3 Video in

These determine what happens when you record video.


3.6 Performance

You will spend most of your time configuring this section. The main focus of the performance section is rendering parameters not available in the rendering dialog.


3.6.1 Background rendering

Background rendering was originally conceived to allow HDTV effects to be displayed in real-time. Background rendering causes temporary output to be rendered constantly while the timeline is being modified. The temporary output is displayed during playback whenever possible. This is useful for transitions and previewing effects that are too slow to display in real time. If a renderfarm is enabled, the renderfarm is used for background rendering. This gives you the potential for real-time effects if enough network bandwidth and CPU nodes exist.

Background rendering is enabled in the Performance tab of the Preferences window. It has one interactive function Settings menu -> Set background render. This sets the point where background rendering starts up to the position of the insertion point. If any video exists, a red bar appears in the time ruler showing what has been background rendered.

It is often useful to insert an effect or a transition and then select Settings menu -> Set background render right before the effect to preview it in real time and full framerates.


3.6.2 Renderfarm

To use the renderfarm, set these options. Ignore them for a standalone system


3.7 Interface

These parameters affect purely how the user interface works.


3.8 About window

This section gives you information about the copyright, the time of the current build, the lack of a warranty, and the versions of some of the libraries. Be sure to agree to the terms of the lack of the warranty.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by root on February 28, 2013 using texi2html 1.82.