Whether it is regarding Cinedeck recorders or cineXinsert, there are a lot of questions about the inner workings of Cinedeck’s true, file-based insert editing. In particular, the reasons for re-wrapping VBR codecs like Apple ProRes in order to allow inserts into a flat, final file.
Quicktime and MXF are not codecs, they are file wrappers and are probably the most misunderstood element in a file’s anatomy. Simply put, a wrapper is a container that carries content. Examples of wrappers are AVI, MOV (Quicktime), MP4, MXF, WAV, etc. The container can be equated to a can that contains some soup and like a soup can, the wrapper includes information identifying the ingredients or, in the video world, the essence (the 1s and 0s that make up the components of the file).
MyVideo.mxf might contain a track of video and 4 tracks of audio. Along with that essence will be information identifying what video and or audio codec was used. The essence could for example be XDCAMHD 50Mbit video with 24bit PCM audio. There will also be timecode data and other information related to the content.
Bit-rate is simply the amount of data used to capture content and generally, a higher bit-rate will mean higher quality. Bit-rate can be expressed in several ways; Mbit/s (megabits per second) and MB/s (megabytes per second) are the most common.
With that as background, it should be pointed out that it is only necessary to re-wrap a ProRes file if the video or Closed Caption data needs to be inserted into. If you are only inserting audio, it is not necessary to re-wrap the file.
Along with the big reductions realized by throwing away less important data, a common method for achieving an additional decrease in size is called Variable Bit Rate encoding or VBR. ProRes is normally a VBR encode while DNxHD uses CBR or Constant Bit Rate encoding.
In simple theoretical terms, if you record an HD shot of a white wall, each uncompressed frame would be 2,073,600 pixels (1920 x 1080) which comes out to about 6 megabytes per frame. Since everything is white, there is a lot of redundant data. To compress this recording a codec might save just 1 pixel per frame with the color white as its data which is about 3 bytes. Then for playback, the algorithm duplicates the single pixel to fill each frame. Thus, a lot less data is saved, yet the same image can be created at playback.
If a basketball bounces through the shot, it changes the equation for each frame. While the encoder needs to do a lot more work to accurately record the shot, some of the image in each frame is still redundant so you can imagine that mathematical tricks can be used to recreate parts of the image with less than all of the original data. In reality, nothing we record is that simple, but similar to the uncompressed recording (which by the way is Constant Bit Rate) a codec using CBR encoding sets a fixed amount of data to be used for each frame. In contrast, VBR sets a “target” and a “maximum” bit rate and then, leveraging factors such redundant data, VBR throttles the data rate used for each frame based on how complicated the images are.
That is really all there is to it… Put in some filler to create equal-sized space for each frame and allow insert editing and then optionally, remove the filler to shrink the file back down a bit. The difference in ProRes file size between VBR and CBR is on average 10% to 30% but that can vary greatly between files and the difference can be minimal for complex content.