Failure modes

The causes of failure reported by ProRes RAW users needing to repair files are:

For the more technically-inclined only!

Little is known about the internals of ProRes RAW encoding. Apple hasn't published technical details and the codec remains proprietary. Besides Apple, nobody knows how to decode images!

We can, however, make educated guesses about how a video frame is structured, and with a small program, we can decode very rough images.

MOV files

First of all, let's start with the easy part, the MOV container.

Footage is stored in .mov containers, like those used in ProRes — one track for ProRes RAW video, plus optional tracks for audio and timecode.

Codec identifiers fourcc are aprn for standard quality and aprh for ProRes RAW HQ.

Frame header looks very similar to ProRes, but with some differences. Let's take a look.

Anatomy of a ProRes RAW frame

This “walkthrough” is intended for people who have some experience digging into files with Hex Editors. To simplify the study, the video frame starts at address 0000.

0000: 00 4F 98 00 70 72 72 66 00 88 00 00 61 70 70 6C
            (1)         (2)    (3)   (4)      (5)
                                        (1) frame length in bytes (32 bits)
                                        (2) frame type, always prrf
                                        (3) header size in bytes (16 bits)
                                        (4) version
                                        (5) vendor (here: appl)

0010: 10 10 08 80 08 08 08 08 00 00 EF 80
       (6)     (7)      (8)
                                        (6) frame width  (16 bits)
                                        (7) frame height (16 bits)
                                        (8) unknown

001C: 3F FD 80 00 3F EF 80 00 3F 0D 9A 80 3E B5 BA 80
002C: 3D 2A BC 00 3D F7 A0 00 3F 89 62 E0 BE 47 2A 00
003C: BD 48 F4 00 BE 98 6C 80 3F B7 C9 00 41 3B DB EC
           (9)
                                        (9) 12 float numbers (48 bytes)
                                            that mirror quantization table
                                            used in ProRes

004C: 00 00 00 07                       unknown (can also be 00000009)

0050: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
0060: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
0070: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
0080: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

0090: 04 91 04 B0 04 8F 04 B6 04 B9 04 E1 04 E1 04 D1
       (10)
                                       (10) slice length (16 bits)

Starting at 0090, for each slice, two bytes encode the slice length.
In this example, first values are 0x491, 0x4B0 and 0x48F.

Number of slices depends on the frame resolution.
Since slices have a fixed resolution of 128 x 16 pixels, we can calculate
the slice count with dimensions found in (6) and (7): 
	4112/128 = 32.125, rounded to 33, 
   	and 2176/16 = 136. 
   	33 x 136 = 4488 slices in each frame.

In the picture, the slices are located following a left-to-right, 
                                                   top-to-bottom order.

Now, knowing slice count, we can go to 0x23A0, after end of slices table.
This is where data of first slice is stored.
Knowing the size of each slice, we can also locate data of any slice.
For example, second slice starts 0x491 bytes after first one, and so on.

Slice header:
Similarity with classic ProRes hints at a DCT encoding (discrete cosine 
transform), but with 4 planes, 2 greens, blue and red, consistent with
camera sensor mosaic pattern.

23A0: 40 2D 01 27 01 2C 01 6F 3F
       (11)  (12)  (13)  (14) (15)
                                    (11) Slice header
                                    (12) length of Green plane (G1)
                                    (13) length of Red plane
                                    (14) length of Blue plane
                                    (15) first DC coefficient of G1 plane

Length of second Green plane (G2) can be calculated with formula: 
                                    Length G2 = (10)-(12)-(13)-(14) - 8
			

From bytes to picture

Having understood how the frame is structured in slices, and having found the main DC coefficient of the each slice and color plane, we can plot a very rough image by setting the luminosity of each slice, a 128 x 16 pixels rectangle, to a value derived from the coefficient.

This is a very bad method to decode an image, but since the codec is proprietary, nobody knows — outside of Apple —  how to interpret the slice data beyond the first DC coefficient.

Writing the program that plots the image based on DC coefficients is left as an exercise for the reader.

Beyond the satisfaction of seeing through the “Matrix”, there is no practical use to doing this.

When we repair ProRes RAW videos, we rely on the decoder provided by Apple that is installed on your machine, so don't worry about image quality, it's as good as originally recorded. You won't notice the difference.