This plugin allows you to load Redcode™ RAW files
(that is: footage shot with a RED ONE™ Camera) in
VirtualDub, the popular video processing application for Windows.
This plugin allows you to load Redcode™ RAW files
(that is: footage shot with a RED ONE™ Camera) in
VirtualDub, the popular video processing application for Windows.
For a better Windows RED workflow, see also my free R3D shell extension.
Important: In spite of what a few articles on the web may suggest, this software is not developed or released by RED. Please do not contact RED with any support questions regarding this product. Read the license below for more information.
By downloading and using the R3D input plugin for VirtualDub you agree to the terms and conditions set forth in this End User License Agreement ("EULA").
The R3D input plugin for VirtualDub ("Plugin") is freeware. You may use it without time or legal restrictions for either commercial or non-commercial purpose.
The plugin was developed and tested by Gábor Kertai ("Author") to his best knowledge, however Author takes absolutely no responsibility that the Plugin works as expected.
You can use the Plugin at your own risk. This Plugin is provided to you "as is", and Author expressly disclaims all warranties of any kind, either implied or express, including but not limited to warranties of merchantability, fitness for a particular purpose, and non-infringement. Author makes no warranty, either implied or express, that any part of the Plugin will be error-free, virus-free, secure, accurate, reliable, or of any quality.
In no event will Author be liable to you for any damages, claims or costs whatsoever arising from this EULA and/or your use of the Plugin of any component thereof.
The Plugin uses technology licensed from RED Digital Cinema Camera Company ("RED") in the form of the R3D SDK, however it has NOT been approved, tested or certified by RED. RED makes no warranties regarding the stability, accurateness and performance of their technology. As per licensing instructions of the R3D SDK, the Plugin is only made available to you in binary format.
You must not reverse engineer, decompile, disassemble or otherwise try to discover the source code of the Plugin and/or the file formats related to RED poducts, especially the Redcode™ RAW (R3D) file format.
The Plugin and any authorized copies that you make are intellectual property of Author and also contain copyrighted material from RED. You agree that all copies of the Plugin reproduced for any reason by you will contain the same copyright and trademark notices as this EULA.
The Plugin may not be redistributed, sold or otherwise made available through any channel other than a download from this website.
RED Digital Cinema, RED ONE, and REDCODE are trademarks of the RED Digital Cinema Camera Company.
Extract R3D.vdplugin from the ZIP file and place it in the plugins32 folder
of your VirtualDub installation. Start VirtualDub. R3D files should now show up in the "Open video file..."
dialog. Note: The plugins32 folder does not exists by default, so
you might have to create it. Do not copy the file into the plugins folder, it will not work there
(it is reserved for older video filters, not for input plugins).
If you open a R3D file, it will be decoded at its best possible resolution and quality (most probably 4K), which may take a good amount of processing time. In the file open dialog check the "Ask for extended options after this dialog" checkbox before opening the file, and you can specify some processing options.
The table below shows what image dimensions you'd get if you fed the plugin with R3D files in certain resolutions and choose any of the different render size settings.
| Render Size setting |
Input file resolution | Description | ||
|---|---|---|---|---|
| 4K | 3K | 2K | ||
| Full resolution | 4096px | 3072px | 2048px | Renders the file at its original resolution. |
| Half resolution | 2048px | 1536px | 1024px | Renders the file at half its original width and height. |
| Quarter resolution | 1024px | 768px | 512px | Renders the file at one quarter of its original width and height. |
| Eighth resolution | 512px | 384px | 256px | Renders the file at one eighth of its original width and height. |
| Sixteenth resolution | 256px | 192px | 128px | Renders the file at one sixteenth of its original width and height. |
| 2K max | 2048px | 1536px | 2048px | Chooses automatically from the above options so that the rendered video is no bigger than 2K wide. |
| 1K max | 1024px | 768px | 1024px | Chooses automatically from the above options so that the rendered video is no bigger than 1K wide. |
Well, they're just the quality settings that the R3D SDK currently offers. Lower quality decoding is somewhat faster. Otherwise I have no clue what the difference is, or what goes on behind the curtains. Feel free to experiment.
OLPF compensation adds some artifical sharpening to compensate for the image softness, which is caused by the optical low-pass filter (hence the name "OLPF") in front of the camera sensor.
Gamma Curve, Color Space, ISO, Kelvin: These allow you to specify some exposure and color correction settings that will be applied to the video when decoding. If you pick "Clip default" then the camera settings (stored in the clip metadata) will be used.
Default button: Pressing this resets all correction settings to use clip metadata values.
RAW button: Pressing this sets correction values so that the resulting image looks much like the "View RAW" option on the camera. Very little contrast with default exposure and color of the Mysteryum CMOS.
Disabled: Audio will not be decoded, even if it exists in the R3D file. You can use this option to save some processing power when you don't need audio at all, or in case you have trouble with the audio in some files.
Mono: Each audio channel will be decoded to a mono stream. You can choose which stream to use in the "Audio" menu of VirtualDub (look for the "Source audio" item). If you have forced silent tracks (see below), then the clip will always have exactly 4 mono streams with complete silence on channels where there was no audio recorded in the R3D file. If you have not forced silent tracks, then the clip will show only as many audio streams as the R3D file contains. In the latter case however there is no guarantee that audio stream numbers will match audio channel numbers from the camera.
Stereo: Audio will be decoded to two stereo audio streams. In camera terms the first stream will have channel 1 on the left and channel 2 on the right. The second stream will carry channel 3 on the left and channel 4 on the right. If any of these channels were not recorded on camera, silence is automatically generated for it.
Add silent tracks: This option is available for mono decoding only. When checked, channels recorded by the camera will be decoded as is, and channels not recorded by the camera will be substituted with silence. You can benefit from this when running batch conversions, because this option guarantees that stream #1 will be camera channel #1 and so on. If unchecked, then streams will only be created for channels that were recorded.
Normalize: Check this option to normalize the audio (i.e. turn up the volume to the highest without clipping). The camera records audio at 24 bits, but it's converted to 16 bits before passed on to VirtualDub, so normalizing before the downconversion should give you better results than doing it afterwards (by way of an audio filter).
The two channels for a stereo stream will be normalized together, so if one of the channels is very loud and the other is very quiet, then the quiet one will not change much. You can use mono decoding to work around this, when each channel is normalized independently.
The normalize function does not check for a noise threshold. If your audio is noise only (such as a channel recorded without a microphone plugged in), it will be amplified to the extreme and sound kind of unpleasant. I might improve this in a future version.
Crop allows you to select a frame aspect ratio to which the decoded image is automatically cropped. Select "Disabled" if you don't want the image to be cropped, or select "Clip default" to use the frame guide setting from the clip's metadata.
Letterbox allows you to automatically add black borders around the decoded image so that it ends up being of 4:3 or 16:9 aspect ratio.
When the Load first segment only checkbox is ticked, and you try to open an R3D file, VirtualDub will refuse to load it if it's not the first segment of a multi-segment clip. This can help you avoid duplicate renders when batch processing directories. (Note: whichever segment of an R3D sequence you open, you always get the same clip, with frames spanning all .R3D files of that sequence.)
Since VirtualDub does not offer any way to remember import options, I've implemented a solution of my own. As of V1.2, there's a Save button at the bottom of the import settings dialog. Clicking this will give you two options to save the current settings.
User global: If you choose this one, the import settings are stored in the Windows registry. They become the "default" import settings for R3D files, so the next time you open up the options dialog, you'll see the same settings show up.
Local config: This is trickier. Well, it's pretty much a hack,
which I conceived because the VirtualDub API lack support for saving configurations.
If you click this button, the
current import settings are saved in a configuration file called
VirtualDubR3D.cfg. The file is placed in the same folder that you
opened the R3D file from, except when the folder is a .RDC folder,
in which case it goes to the parent folder. This configuration file will affect
every R3D file opened from the folder in which the config file is, and every
subfolder thereof.
Here's what happens config-wise, when you open a clip: First, the user global
defaults are loaded from the registry. Then the plugin looks for a
VirtualDubR3D.cfg file in the directory of the R3D file. If it's found,
it's loaded. If not, then it keeps looking in all parent directories, until
it finds one, or it reaches the root of the directory tree.
Latest version: VirtualDub_R3D_Input_V1.4.zip (396.6 kilobytes)
Older versions:
VirtualDub_R3D_Input_V1.3.zip (343.1 kilobytes)
VirtualDub_R3D_Input_V1.2.zip (340.5 kilobytes)
If you need something to experiment with, but don't have any recordings of your own, you can grab sample R3D files from the Official Red User Forums.
Is this open source software? Is the source code available?
No and no. However much I'd like to make this open source (or even GPL), the R3D SDK license agreement clearly states that I cannot make their source code public. I cannot even release the parts of the source code that I've written without their header files, because their licensing prohibits me from revealing any details about their header files, and so releasing code that calls the R3D SDK functions in itself would violate the license.
This means that source code is not available on request either. The only possible exception is if you are a licensed R3D developer yourself, but I'd have to ask RED about this, should the question ever arise.
I'm more than sorry to have to play it this way. If RED ever decides to ease the SDK licensing limitations, I'll rethink the possibilities.
Can I redistribute this plugin bundled with VirtualDub?
No. There's a conflict between VirtualDub's GPL and the R3D SDK license agreement which prohibits this. You can however refer your customers to this website to obtain a free copy of the plugin. See the plugin license above.
Is there a 64-bit version available?
Not at this moment.
Does the plugin support Unicode?
No. It is a limitation of the R3D SDK. The VirtualDub plugin SDK is fully Unicode compliant, but the plugin converts file names to ANSI internally.
Since R3D files originated from the RED ONE™ camera are using only ASCII characters in their file names, the only problem you might have is with directories. Try to avoid non-ANSI path names if you can.
Does the plugin support the Red Rocket acceleration card?
Unfortunately no. The rocket is an expensive piece of hardware and I don't own it myself, so I would have no way to test/debug its functionality. I do not have plans to purchase the product any soon, nor do I know of anyone in my vicinity to own it. I have received offers from people to test the plugin for me on their own Red Rocket systems, but since I'm not allowed to give out debug information (as per the R3D SDK licensing), it would be nearly impossible to fix any bugs that way. Sorry.
Can I load segments (*_001.R3D, *_002.R3D) separately?
Unfortunately no. The R3D SDK gives me very little control over loading and parsing the R3D files. Whichever segment you open, you'll end up with the same (full) video sequence.
There's an option in the input settings dialog to disallow loading second, third, etc. segments of a file. This can be a lot of help when batch processing directories.
Can I encode to R3D?
No. That is for two reasons. First, VirtualDub can only encode to the Windows AVI container format, and there is no R3D decoder for that format, so it would be fairly pointless. Second, the R3D SDK currently does not support encoding.
Do you blame the R3D SDK for everything?
Absolutely not. Some features were not implemented simply because I did not need them badly enough and I only had a limited amount of time to devote to this project. If you need something added, do not hesitate to contact me and we'll talk about it.
Note however that the R3D SDK is in its early stages of development and as it evolves, you're going to see more features added to the plugin too.
Does the plugin work with other software supporting VirtualDub filters?
Can't say. It's a very conformant input plugin, so theoretically is should, but I haven't tested any such application. Do please let me know if you have success (or failure for that matter) in this regard, so that I can post it or fix it.
Do you have a forum to discuss the plugin?
Not one that I maintain. There are however a topics on the RED User forums where you can post and look for answers.
How do I batch convert all the clips in a directory?
This can be tricky, because when grabbed from the camera, all the R3D clips are neatly organized in severeal subdirectories, but the batch conversion mode in VirtualDub just won't load them recursively.
Probably the easiest workaround is to move all the R3D files into a single folder and use the "Process directory..." command in the VirtualDub Job Control window. Make sure to have the "Load first segment only" checkbox checked on the "Open file options" dialog and saved as a global config.
While moving the R3D files does no harm, I know that it may be unacceptable to some, so here's a different workaround:
virtualdub_settings.vcf in this example.FOR /R %n IN (*_001.R3D) DO "C:\Program Files\VirtualDub\vdub.exe" /s virtualdub_settings.vcf /p "%~fn" "D:\full_path_to_destination_AVI_folder\%~nn.avi" /xC:\Program Files\VirtualDub folder, if not, change that accordingly.
Also insert the full path of your destination folder where it says so.
You can as well create a batch file out of this (just make sure to replace every % with %%),
then you only need to copy it into your R3D root folder and double click.
Use the line "C:\Program Files\VirtualDub\vdub.exe" /c /x at the beginning of the batch file to clear
VirtualDub's current batch job list and use "C:\Program Files\VirtualDub\vdub.exe" /r /x at the end to
start processing the batch job.
My clips open with all kinds of weird settings. What's going on?
Most likely you saved those weird settings using the "Save as Local"
command from the "Open file options" dialog and then forgot about them. Check
if you can find VirtualDubR3D.cfg files in the folder you're trying to
load the clips from, or any of their parent folders. Delete them if you think they're
no longer needed.
Why do I get distorted images when I load an R3D file?
I'm not sure, I've never experienced this myself. However one user reported having distorted images show up, which he could fix by enabling the "Use GPU" check box on the VirtualDub preferences dialog. I can't seem to have anything named "Use GPU" in my version of VirtualDub, so I don't exactly know what he meant.
If you're handling Redcode™ RAW files on Windows, you will probably find my R3D Shell Extension useful.
If you're into AviSynth scripting, check out my R3D source plugin for AviSynth.
Should you have any useful feedback, bug report, comment or idea for improvement,
you can reach me at 
.
I reserve the right to ignore any emails with a bad attitude or lack of respect.