Rendering
- 6-16-2008
- Categorized in: Encoder reviews
Now you’re ready to render, which you can do in two ways. Click Convert, and you’ll encode the files serially with Carbon Coder’s main interface. Or, you can click Queue to encode the files in the updated Carbon Administrator, which opens the Job Queuing window shown in Figure 2.
Figure 2. The Job Queuing window, which sends the files from Carbon Coder to Carbon Administrator.
On a multi-core system, click the One Job for each Target button in the middle of the window, which enables Carbon Coder to more efficiently assign processor cores to the encoding job. If your version of Carbon Coder is part of a rendering farm, you would click the Render in Network Grid checkbox on the bottom to send the files to rendering farm.
Then click Queue to send the encoding jobs to the encoding engine. To watch your progress, open Carbon Administrator, the other program installed when you set up Carbon Coder, and shown in Figure 3. Operationally, you’d always want to check the Kernel Settings to make sure you have as many Transcoding Slots as you have cores in your system. I tested on an HP xw8400, a 2.6 GHz Dual-Processor, Quad-Core computer, with a total of eight cores, so you can see 8 slots in the Figure.
In my tests, I started with 18 files, to which I encoded to the four presets shown in Figure 1, for a total of 72 encoding tasks. Behind the Kernel settings, you can see the first eight jobs encoding in the Active Jobs tab. In the Job Status box just below the menu bar, you can see the 8 Active jobs and the 64 Queued Jobs, which you could view by clicking the Queued Jobs tab in the window. Separating jobs into four tabs was one of the main interface upgrades in this version of Carbon Coder, as well as folding the enhanced Watch Folder functions into the same window.
Figure 3. The updated Carbon Administrator. Note the new tabs that separate jobs into helpful categories and the integrated Watch Folder functionality. Click the figure to view the image at full resolution in a separate window.
Encoding trials immediately revealed that Carbon Coder remains highly tuned for fast, multi-processor efficiency. The unfortunate competitor in this round of testing was the newest version of Sorenson Squeeze, the first with Simultaneous encoding of multiple files. To be fair, Squeeze costs about 90% less than Carbon Coder, so keep that in mind when reviewing these numbers.
Table 1: Performance times in min:sec, Carbon Coder vs. Squeeze.
The first two lines of Windows Media testing illustrate how efficiently Carbon Coder can encode multiple files simultaneously, or in parallel in computer speak. The first line shows how long it took to render eight one-minute test files serially within the main Carbon Coder interface (26:31), the second how long it took to render the files in parallel in Carbon Administrator (11:11). This is a drop of about 57%, compared to only 10% for Squeeze. I
Though not shown in the performance table, note that Squeeze can’t produce multiple Flash files simultaneously using the On VP6 codec. Carbon Coder can, and proved 56% faster when encoding in parallel. Squeeze also couldn’t simultaneously encode multiple files using the MainConcept H.264 encoder, the same used by Rhozet. Though Carbon Coder could encode to H.264 format in parallel, the time savings were not significant.
Back to the performance table, the next two lines illustrate performance efficiencies when producing files to multiple formats. As you can see, when producing one file to Windows Media, H264 and Flash VP6 using the On2 SDK (software development kit), Squeeze was actually faster than Carbon Coder, primarily because Carbon Coder is less efficient than Squeeze when producing single Flash files using the On2 Flash SDK.
Probably for this reason, Rhozet switched to the Adobe SDK, which is multi-threaded, allowing multiple cores to help produce the same file, and also only supports one pass encoding. I discuss the qualitative aspects of this switch below, but it’s obviously a winner when it comes reducing encoding time.
Figure 2. The Job Queuing window, which sends the files from Carbon Coder to Carbon Administrator.
On a multi-core system, click the One Job for each Target button in the middle of the window, which enables Carbon Coder to more efficiently assign processor cores to the encoding job. If your version of Carbon Coder is part of a rendering farm, you would click the Render in Network Grid checkbox on the bottom to send the files to rendering farm.
Then click Queue to send the encoding jobs to the encoding engine. To watch your progress, open Carbon Administrator, the other program installed when you set up Carbon Coder, and shown in Figure 3. Operationally, you’d always want to check the Kernel Settings to make sure you have as many Transcoding Slots as you have cores in your system. I tested on an HP xw8400, a 2.6 GHz Dual-Processor, Quad-Core computer, with a total of eight cores, so you can see 8 slots in the Figure.
In my tests, I started with 18 files, to which I encoded to the four presets shown in Figure 1, for a total of 72 encoding tasks. Behind the Kernel settings, you can see the first eight jobs encoding in the Active Jobs tab. In the Job Status box just below the menu bar, you can see the 8 Active jobs and the 64 Queued Jobs, which you could view by clicking the Queued Jobs tab in the window. Separating jobs into four tabs was one of the main interface upgrades in this version of Carbon Coder, as well as folding the enhanced Watch Folder functions into the same window.
Figure 3. The updated Carbon Administrator. Note the new tabs that separate jobs into helpful categories and the integrated Watch Folder functionality. Click the figure to view the image at full resolution in a separate window.
Encoding trials immediately revealed that Carbon Coder remains highly tuned for fast, multi-processor efficiency. The unfortunate competitor in this round of testing was the newest version of Sorenson Squeeze, the first with Simultaneous encoding of multiple files. To be fair, Squeeze costs about 90% less than Carbon Coder, so keep that in mind when reviewing these numbers.
Table 1: Performance times in min:sec, Carbon Coder vs. Squeeze.
The first two lines of Windows Media testing illustrate how efficiently Carbon Coder can encode multiple files simultaneously, or in parallel in computer speak. The first line shows how long it took to render eight one-minute test files serially within the main Carbon Coder interface (26:31), the second how long it took to render the files in parallel in Carbon Administrator (11:11). This is a drop of about 57%, compared to only 10% for Squeeze. I
Though not shown in the performance table, note that Squeeze can’t produce multiple Flash files simultaneously using the On VP6 codec. Carbon Coder can, and proved 56% faster when encoding in parallel. Squeeze also couldn’t simultaneously encode multiple files using the MainConcept H.264 encoder, the same used by Rhozet. Though Carbon Coder could encode to H.264 format in parallel, the time savings were not significant.
Back to the performance table, the next two lines illustrate performance efficiencies when producing files to multiple formats. As you can see, when producing one file to Windows Media, H264 and Flash VP6 using the On2 SDK (software development kit), Squeeze was actually faster than Carbon Coder, primarily because Carbon Coder is less efficient than Squeeze when producing single Flash files using the On2 Flash SDK.
Probably for this reason, Rhozet switched to the Adobe SDK, which is multi-threaded, allowing multiple cores to help produce the same file, and also only supports one pass encoding. I discuss the qualitative aspects of this switch below, but it’s obviously a winner when it comes reducing encoding time.
