Insert Edit and VBR File Re-wrapping


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.

Codecs, wrappers and bit-rate all work hand in hand but they are three distinctly separate things. For our purposes, a codec is a compression algorithm used to process video and reduce the size of the resulting file, while maintaining a certain image quality level. Examples of Codecs are Avid DNxHD, Apple ProRes and MPEG2.

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.

Video files, especially those of high quality, are large and potentially require massive amounts of disk space for storage. As a comparison, a typical text document today might be a megabyte in size while a typical HD video file can easily be hundreds of Gigabytes. Because of these massive file sizes, various types of compression algorithms were developed to help reduce file size. All of these codecs use various formulas to throw away data considered “less important” and all of them are optimized for somewhat different requirements. For example, XDCAMHD is relatively small, but to achieve its size, a “Long GoP” structure is used which can introduce artifacts some find undesirable. If you compare files of a similar visual quality, you will often find that the file size is also similar so for example ProRes HQ is similar in size to DNxHD 220.

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.

Cinedeck’s insert edit uses some interesting techniques to locate and replace content in your files. Part of that science is knowing that each frame is the same size. So a CBR DNx file presents no issues, while a VBR ProRes recording does present some limitations. So, we re-wrap the ProRes essence; which is essentially a file-copy process of pouring the ProRes out of one container into another while simultaneously adding some amount of Zeros to each frame to make them all the same size. Once the frames are uniform, the Cinedeck application can more easily access and rewrite specific frames. When finished, the file can again be re-wrapped back to VBR by pouring the essence into a new wrapper while simultaneously removing the unneeded Zeros from each frame.

vbr-cbr_bucket-analogy_transp

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.

vbr-pic
cbr-pic