Common NLE System Workflow

1. The NLE system requests a frame or field from Graphics Plugin.

2. Graphics Plugin checks its configuration and connects to the Viz Engine over the network.

3. When connected, Graphics Plugin queries Viz Engine for basic information, loads the relevant graphic scene, sets the correct values in the scene, and stretches the graphics to fit the effect in the NLE project.

4. Graphics Plugin requests fields and frames from Viz Engine according to the NLE system requests.

5. Viz Engine receives the requests and ensures that the right scene is loaded and moved to the right frame or field, and sends the graphics back over the network.

6. Graphics Plugin receives the graphics and sends them back to the NLE system.

7. The NLE system processes the data it received before requesting more graphics, repeating the process.

Although the workflow described above is easy to follow, functional and easy to test, it's slow since the NLE system only requests a single frame or field at a time and is blocked until a reply is received. Graphics Plugin sends the request to Viz Engine and must wait for a response before in turn sending its response back to the NLE system.

Challenge 1 - A Big Volume of Data

A big amount of data is being sent; for example, a simple interlaced HD (1080i) field with full alpha is 4MB (1920*540*4 bytes), which takes some time to transmit. Rendering a five-second interlaced HD clip at 50 frames a second requires more than one gigabyte of raw data to be rendered and processed by Viz Engine, sent over the network, received by Graphics Plugin, and then moved into the buffers provided by the NLE system, at which point the NLE system must process the data.

Challenge 2 - Latency

In addition, every network has latency and is affected by other network traffic. Waiting for 4MB requests to return and for the NLE system to process the graphics further takes time and is inefficient. To reduce this delay, Graphics Plugin therefore strives to fields or frames ready when the NLE system sends a request. The plugin tries to accomplish this by keeping the network and Viz Engine continuously busy. It attempts to predict the NLE system's next request by requesting graphics from Viz Engine in advance. Once Viz Engine has received the request, it renders and sends the graphics back to Graphics Plugin, which processes it to fit the NLE system.

A number of factors affect this workflow:

• The TV-standard, for example, PAL is a lot smaller than 1080i and is quicker to render, process and send over the network.

• The CPU and GPU of the Viz Engine define how fast it can deliver graphics. As always, a better graphics card, faster CPU and more memory helps.

• The network card on Viz Engine and the NLE client machine.

• The network capacity defines how much data can be sent over the network.

• The compression of the data determines both how much CPU is used on Viz Engine to compress and on the client to decompress, as well as how much data is sent over the network.

• The amount of ask-in-advance requests keeping the renderer and the network busy.

• The processing the NLE system needs to do with the data it receives (affected by CPU and/or GPU, memory, software, and so on).

Improving Performance

Some things can be improved by adding hardware to the renderer and the clients, and by using as fast a network as possible. In addition, NLE system processing greatly impacts performance. Other things can be configured, either by the plugin or by convention:

• File Compression

• Prefetching

• Testing for Concurrent Use

See Also

• Optimizing System Processing