REDCODE

REDCODE RAW (R3D) is a proprietary multimedia audio/video file format owned by Red Digital Cinema Camera Company and featuring lossy compression for both audio and video contents. It is used as native recording format of the Red One 4K digital camera and recorded on proprietary Hard Disk Drives or CompactFlash cards, but can be extracted from there and be trivially handled in any file-based audio/video, IT and home environments.

Compression algorithm

Video streams within a R3D file are stored using a variable bit-rate, frame-by-frame, wavelet-based codec with four channels (1 for red, 2 for green, 1 for blue), which is a variant of the well-known JPEG2000 algorithm for digital still images.

Decompression is not the only coding the video stream is subject to in order to be playable: since the video data recorded from the camera sensor (the Mysterium sensor in the case of the Red One camera) are stored in the geometrical order they are transferred, a Bayer-patterned frame sequence is generated in the first place, which needs later transcoding (deBayering) to obtain a visible RGB stream. For that reason, R3D is a raw image format for video. A similar file format (or wrapper) is the Adobe CinemaDNG.

Audio streams (mono, stereo or 4-channels) are coded, uncompressed, in plain 48 kHz, 24-bit PCM.

For more information, please cfr. the Red One compression and workflow.

Naming convention

R3D files, as generated by RED's digital cameras, have a symbolic naming convention whose aim is to both uniquely and unambiguously reference each clip/take which has ever been shot every day by each camera, as well as aiding during the online editing and post-production phases to discern which reel, camera and shooting date combinations that clip "belongs" to.

RED Digital Magazines

R3D files are first arranged into former-level folders, called RED Digital Magazines (RDMs); a RDM folder is created for each storage medium initialized (i.e. soft-formatted) and used by a RED digital camera and for every day of shooting (according to the camera's own internal clock). The RDM directory associated to camera (cam.) X (where X ranges from A to Z), equivalent of a traditional 3-digit reel number NNN, shot on the dd^th (2-digit) day of the mm^th (2-digit) month of any year is named X NNN_dd mm HH.RDM. In this case HH is just a hexadecimal hash code to make that clip universally unique.

RED Digital Clip

Inside each RDM, lower-level subfolders are generated for each take shot by the camera (i.e. sub-directory creation is triggered by the camera's record start/stop button): those are the RED Digital Clipss (RDCs). Takes are chronologically referenced by an increasing number within each RDM such that, apart from the hash code (which is RDM-independent), the TTT^th (3-digit) take from the above RDM is named X NNN_C TTT_dd mm HH.RDC.

R3D digital contents

Each take is stored in one R3D stream, by one or more R3D file with the same name as the RDC containing it, but with a .R3D file extension. Since R3D files are limited to a maximum size of 2GiB, upon reaching this limit, a new R3D file (with an appended _ppp tail for the ppp^th, 3-digit part) is generated within the same folder, whose contents are the raw continuation of the former one.

Other files

A RDC folder always stores, apart from the R3D files of that specific take, four wrapper QuickTime files. These are just metadata containers without stream contents (they are a few kilobytes large) and must reside together with associated R3D file(s) in the same folder, otherwise they are useless. Once opened by a QuickTime Player utility with a R3D codec installed/binded, they point to the R3D file and allow normal playback of the latter file(s) as if they were normal compressed-video files. The four QuickTime proxies also automatically set the playback frame size to either full-resolution (_F filename suffix), halved, one-fourth or one-eighth resolutions (_H, _M and _P suffixes respectively).

There is no real need of these four QuickTime containers though, if the R3D files are to be processed by software natively supporting the REDCODE codec.

Other than that, additional files may be present inside a RDC folder, as generated by either the camera and intermediate software as well. Among these there might be content-indexing ASCII or XML files, as well as RSX files (same name as the RDC with .rsx extension), automatically generated by Red's proprietary software and keeping shooting-time and offline colour-correction / pre-grading information. Such metadata may be later used for either later previewing, offline editing and DI conforming.

R3D metadata file format specifications

Apart from the audio/video codec itself, which is proprietary and closed-source but made public via a SDK licensed by RED, some details about the container and metadata within R3D files generated by a Red One camera have been partially reverse-engineered by several, independent projects.

First of all, metadata are recorded at both the beginning and ending of the R3D data stream, that is as the file header in the first R3D file, as well as a file footer in the last R3D file making the stream.

The file format's magic number is "0₁₆0₁₆1₁₆DRED1", which also defines the beginning of the file header on the first R3D file. The stream tag "REO" marks the end of the whole R3D stream (the end of the clip recording, 52 bytes from the EOF), i.e. the file footer of the last R3D file. The header stores a priori information on the clip like camera/storage settings/serials, firmware versions, start TimeCodes (read below), plus frame-, audio- and file-format settings, including colorimetry as well as on-camera colour-correction parameters. The footer stores a fortiori information instead like, most notably, the overall clip duration in frames; from the latter and the knowledge of the record frame-rate, the clip's ending TimeCodes can be easily recovered.

A R3D file is internally organized into substreams, mainly containing small chunks of audio or video contents (as well as other metadata). These chunks are sequentially stored within the R3D file and initiated by specific tags (REDV for video chunks, REDA for audio chunks) for synchronization purposes during file playback. The initial video chunk in a R3D stream (the first REDV chunk in the first R3D file of a RDC) also happens to include the file header itself.

Most notable metadata are recovered at absolute positions within the header, according to this table (offsets are expressed in 0-based bytes from the start of the first R3D file):

Within the file header, each metadata starts with a 16-bit identifier, which is a "10₁₆" character followed by the metadata's ordinal number ("00₁₆" being the first one). Metadata are typically written in order, although not all are consecutively defined (e.g. those whose ID starts with "100₁₆" refer to TimeCode-based chrono-timing, those starting with "103₁₆" are information about recording media, and so on). This format is reminiscent of JPEG standard, used for both JFIF and Exif metadata encoding, as well as binary internal tagging used for TIFF file format's metadata.

Metadata are written as either plain ASCII strings, words, IEEE floating-point values, or other proprietary codings; strings can be either fixed- or variable-length (metadata IDs allow the header's elastic syntax), but they end in both cases with either a NULL ("00₁₆") byte or "000F₁₆".

The following table contains some of the reverse-engineered metadata within a R3D file header. First column contains the (decimal) metadata ID: for example, metadata ID #42 (hexadecimal "2A₁₆") is coded, within the file header, just after the string "102A₁₆".

From the file footer (i.e. the final part of the last R3D file of a clip) the number of frames can be simply recovered as being a word (16 bits) 30 bytes from EOF.

External links

• Red Digital Cinema Camera Company official website
• REDuser.net forum
• Official FFmpeg website

yo:REDCODE