Raylight Ultra and Sony Vegas 9

Sony Vegas Pro 9.0, like previous versions of Vegas, does not support MXF files created by Panasonic camcorders such as the HVX200. (For more on the significant new features that Vegas Pro 9 does offer, see Jim Harvey's review on Creative COW.)

Perhaps Sony feels little pressure to support its rival's format as a standard, out-of-the-box feature, since the need has been addressed successfully by Austin, Texas-based DVFilm with its $195 Raylight plug-in. Last year I reviewed Vegas 8 and Raylight, which I noted "elegantly and reliably marries Vegas and Panasonic MXF". I also observed that Sony seemed to have made a strategic decision to use Raylight as the preferred way of getting Panasonic MXF files onto the Vegas timeline. That still seems to be the case. In fact, as far as I know, DVFilm products are still the only way to use Panasonic MXF files in Vegas without having to convert the MXF files into a different format first. Sony supports its own version of MXF (XDCAM) in Vegas, but not Panasonic's (P2); instead, Sony cooperates with DVFilm to support Panasonic MXF.

Now DVFilm has released Raylight Ultra as the successor to Raylight. Although DVFilm continues to support Raylight, future development efforts will be focused on Ultra. (By the way, there is no Ultra for Adobe Premiere Pro, since Premiere has had built-in support for Panasonic MXF files since version CS3.)

I have mostly used Raylight, and now Ultra, for their core functionality, that is, coding/decoding MXF files. (Because this is their core functionality, they are often described as codecs, even though the products also include the Raylight Plug-in for Sony Vegas; RayMaker, an application that converts MXF files into AVI files; P2 Maker, an application that converts Raylight AVI into MXF files; and a control panel for the Raylight codec.) That core, in my experience over several months, is solid.

For this review, I ventured into some of Ultra's "added features" and found a couple of problems, but at this point only an issue with the "suppress recompression" feature remains. DVFilm is working on that. (I tested primarily with Raylight Ultra 1.1.) I'm guessing these problems reflect typical version 1 birthing pains, since according to DVFilm Ultra is all-new code, not just a revision of the previous Raylight code.

Improved Performance

Probably the most important new feature in Ultra is improved performance, which makes it more likely that you'll be able to edit in real time, at full resolution, with smooth playback and good visual fidelity. Prior to Ultra, it was expected that, when previewing on the timeline, you would have to make a choice between previewing full-resolution video and getting smooth playback. You'd typically have to render the project to see full-res smooth playback. Ultra's improved performance makes it more likely that you can get the best of both worlds when previewing on the timeline.

This improvement is reflected in the fact that Ultra has just two editing modes, where the previous version had four. In both new and old versions, there is a Raylight Red (Low Res Proxy) mode designed to allow you to work in real time ( though with a significantly degraded image) even on a slow machine or with a very demanding project..

The difference between the new and old comes at the high end. In the previous version, the best mode from a visual perspective, Raylight Blue, was not designed to support real time previewing on the timeline. With Ultra, the Raylight Ultraviolet (Max Quality) mode is intended to be both maximum quality and real time. Of course, the computer you're running on and the complexity of your Vegas project will enter into the equation in determining whether you actually achieve that or not.

The Ultra Settings screen with radio buttons at the top for Ultraviolet and Red modes

When it comes to performance for previewing, the weakest link in the chain determines your experience. That means that factors other than the Raylight codec (hard disk speed, the complexity of the Vegas project, processor speed) may play a more decisive role in determining your editing experience than the efficiency of the codec.

One of the most demanding things I tried to do with Ultra was to preview three superimposed tracks at 1920 x 1080. The top two were masked so that part of each of the three tracks was visible. There were no filters or special effects on the video. There were also three tracks of audio and a checkered background created using the Vegas "generated media" capability.

This generally previewed smoothly on an HP XW4600 workstation running Windows XP Pro, although a couple of times the top video track disappeared for an instant, so all that was previewed for that instant were the two video tracks below it. Often this would happen a second of two after I started playing the video, after which everything proceeded smoothly.

But, for my needs, most of the time, Ultra achieves its goal of editing in real time with high quality.

If you're not able to get smooth full-resolution playback with Ultra, the bottleneck is most likely something other than Ultra. You should probably try things like putting video files on a separate dedicated disk (instead of storing the Vegas project file and the video files on the same disk) and defragmenting your hard disk. Or you may need a faster hard disk or processor.

You'll notice that there's a checkbox on the Ultra configuration screen for "Mark Red/Yellow/Green". (You can see it in the lower left portion of the figure above.) Selecting this checkbox creates a colored border around video rendered at less than maximum quality; the color of the border indicates the quality. I originally thought that, with Ultra, the checkbox should just be labeled "Mark Red", since that is the only less-than-maximum quality setting for MXF files in Vegas 9. In reality, for backward compatibility, the Green and Yellow modes are available in Ultra–with AVIs or with Vegas 8 . These were included for backwards compatibility. You access them by using the old, four-button Raylight control panel which was re-created for Ultra. This is documented in the help file, last sentence of section 5. The help file also provides a link for downloading the four-button control panel if you need it.

"Fast Render": and "Auto Mode" are items on the Ultra configuration screen that Ultra does not use. They should have been removed.

Ultra Red Alert

Even in the best of circumstances, using the "Red" (low-res) preview mode is a bit of a pain. Before you can use it, you have to create low-res proxies, using DVFilm's RayMaker. This is a batch process that can take a significant amount of time, depending on the number of files. The proxies also take up disk space (generally, about a third to a half as much space as the original MXF files). You actually drag the AVI proxy onto the timeline. Depending on how Ultra is configured (for Red or for Ultraviolet) it displays the proxy itself or the full-res clip.

Because of the extra hassle involved, I personally have avoided Red ever since Raylight stopped requiring proxies and started allowing you to just drag MXF files directly into the timeline. If I'm not getting smooth playback (usually because of multiple video tracks with masks, filters or special effects), I just preview at a lower resolution, by making the preview window smaller and using the "Preview (Auto)" mode in Vegas. If I really need to see full-res 100% smooth video with one of these demanding sections, I do a test render.

I initially had trouble getting Red to work on either of the machines I tested on (an HP XW4600 workstation running Windows XP Pro and an HP Pavilion laptop running Vista). However, the problem was fixed in Ultra 1.1.1. If you're running Ultra 1.1 and have a problem with Red, be sure to upgrade.

Suppressing Recompression

Ultra has a "suppress recompression" feature which is intended to allow the codec to bypass compression / decompression in situations where it is superfluous, that is, when the output from the codec is supposed to bit-for-bit the same as the input. To use this feature, you have to use the Raylight codec when setting up your render in Vegas. Then you can click the Configure button by the codec selection dropdown (see figure below) and make sure that "Suppress Recomp" is selected on the Ultra configuration screen (shown below).

The Configure button on the DVFilm Raylight Ultra Settings screen

The Ultra help file says that the Suppress Recomp feature "creates non-recompressed Raylight AVI’s from either AVI’s or MXF files. The codec calculates a checksum or signature on each frame handed to the editing system. On compression of frames when rendering a raylight AVI, the codec recalculates the checksum to see if it has changed. If it has not, then it uses a saved copy of the compressed frame (the original camera data). This speeds up processing because the compression step is skipped, and it also improves image quality because unnecessary recompression is eliminated."

I had a terrible time with this feature. Over the course of eight rounds of testing -- probably around 40 individual renders or render attempts -- this feature worked for me once.

First, after I failed to get it to work in Vegas 9, I consulted DVFilm support, who told me that Suppress recompression does not work in Vegas 9 with MXF files. (This is now documented at http://dvfilm.com/raylight/ultra/help.htm, end of section 12.)

They also forwarded an explanation, namely that the Vegas 9 plug-in does not use the Raylight VFW (Video for Windows or AVI) codec like the Vegas 8 plug-in and all previous versions, "since the VFW system is not available in 64-bit systems and we had to make it work with Vista 64. It has its own copy of the Raylight codec. So the codec data cannot be shared between the MXF plug-in and the VFW (AVI) codec, which is how suppress recompression works for MXF files."

They added that, "If you need non-recompressed editing you can either edit with Raylight AVI source files or wait until we have the direct MXF export feature working for the Vegas 9 plug-in, which will be available later this year, or use Vegas 8."
I tried using Vegas 8, also with little success, even after many attempts with different render setups, project setups, etc. My worst failures were Raylight DLL errors, which also caused Vegas 8 to exit silently (no error message) when I tried to render. (DVFilm has reproduced this error and is working on a fix.)
On most occasions, the render worked, but recompression was not suppressed. The timecode in the rendered file is supposed to tell you whether you have recompressed or not, and it always indicated recompression. The Ultra help file says you can tell non-recompressed footage because the timecode burn-in of the rendered section will be the same as the original camera timecode. Otherwise, if the section is recompressed – for a dissolve for example – the timecode will start at zero. In my testing, I used the same MXF clip twice in a row. If compression had been suppressed, the timecode in the render should have started at the same time as the original clip and jumped back to that time midway through the rendered file – in other words, it would have exactly mirrored the source timecode. That happened only once.
In an email, Marcus van Bavel, DVFilm's chief engineer, told me that somewhere between version 8.0 and 8.0c Vegas began to export AVI from YUV format frames rather than RGB frames, using a YUV format that Ultra doesn't support yet.
"In fact we were not even aware that they changed it (and of course they didn't tell us). And that's the reason you cannot export with suppress recompression," said van Bavel.
The problem is that Ultra is trying to checksum frames that are smaller than expected.
"Since we have not released 1.2 yet," said van Bavel, "there is still some hope it will be fixed in that release."
Once Ultra is modified to support this feature, I recommend (based on DVFilm's attempts to help me) that you proceed as follows when suppressing recompression:

• Be sure of the frame resolution, frame rate and field order of your original footage. For instance, mine was 1920 x 1080, 29.97 frames per second, upper field first. (In Vegas, the preset for this is "HD-1080-60i".) Also, check your audio settings. My original audio was 48KHz sampling rate, 16 bit. I got this information for the raw footage by looking at the metadata or "clip" (XML) file created by the Panasonic HVX200 when it writes the footage to the P2 card.
  
  
• Make sure your Project settings (File > Project Settings) match your original footage.
  
  
• Check to make sure Vegas is reading the footage correctly. One way to do this is by right-clicking on the clip in the timeline, then selecting Properties and going to the Media tab. To check a lot of clips, it's easier to look in the Project Media window (View > Project Media or Alt-5).
  
  
• Make sure you render with these same settings.

Metadata

A potentially useful feature of Ultra is metadata slating. Basically, this takes metadata information from the P2 "clip" file (the same XML file mentioned in the previous section, automatically created by the camcorder when recording) and puts it on the first or second frame of the clip on the timeline. By default, Ultra is configured to show the slate on the first frame. This configuration is shown in the screen shot below.

The metadata slate configuration section on the Ultra Settings screen

The screen shot below shows a sample slate.

The metadata slate in the Vegas timeline

Note that slates do render. So you'll definitely want to turn the slate feature off before a final render.

I was initially confused when a slate failed to appear on one clip, the first clip on a particular P2 card. I had failed to read the part of the help file that says, "The slate never appears on MXF files that are a continuation of a spanned clip."

Spanned clips are created when a single clip (from a logical perspective) needs to be recorded in two different physical files. This can happen for one of two reasons: First, the FAT file system used by P2 camcorders such as the HVX200 can't handle files larger than about 4.2GB. So, if a single clip would exceed that maximum size, it is divided into two or more clips. Second, if a P2 card fills up, and a second P2 card is available that is not full, the camcorder automatically and transparently switches over and starts writing to the second P2 card. The result is that half of the logical clip is on one P2 card and half on the other. Again, two physical files form one logical clip.

Ultra only slates the first physical clip for each logical clip. This can be helpful, since it means that where you see multiple physical clips on the timeline, the slates mark the logical clips. For instance, in the figure below, there are three physical clips but just two logical clips. The first two physical clips are one logical clip, so only the first one is slated. (The third clip is so short that only the slate is visible on the time line at this particular level of timeline expansion.)

Three physical clips, with the first two spanned

Another interesting metadata feature is mapping the P2 "UserClipName" to the "Tape Name" in the Project Media window in Vegas. In the field, the camera operator can use P2 CMS or P2 Viewer software (both free from Panasonic) to give each clip a useful name like "CU Bob Take 2". The P2 camera can also increment the last number in the clip name automatically.
The user clip name will appear in the Project Media window in Vegas as the Tape Name (assuming you're in "Detailed" view). You may prefer to drag the "Tape Name" column over to the left, perhaps positioning it next to the MXF file name.
You can also sort the clips alphabetically by user clip name. This makes it easier to find a particular clip.
"It's much better than having to view each clip and then add a comment in Vegas," said van Bavel. "The cameraman pre-names the clips so the editor can start editing sooner. This is the big advantage to P2 editing vs tape."

I give Ultra four and a half cows, since its core functionality (all I really care about) is great, but I had problems with the "suppress recompression" feature.