ProRes Insert Edit Explained

There are a lot of questions about the inner workings of Cinedeck’s true, file-based insert editing. In particular, how and why we create insert-editable ProRes files. Read on to find out more.

In our analogy:

  • The Book = A File
  • Words on Pages = ProRes Encode of content
  • Chapters of the book = Frames of ProRes
  • Table of Contents = File Wrapper
  • Booking Binding = Exporting a File
  • Blank Pages = Padding

A Standard ProRes File:

Imagine that a standard ProRes file is a book. Depending on the content, each chapter is a different length of pages based on how many words there are. Also, each chapter starts where the previous chapter ends. The book’s table of contents tell us which page to go to if we want to go to the start of chapter 23, for instance. Finally, if there’s a typo or if we want to add a paragraph in a chapter, we must throw out the book, print all new pages then rebind a brand-new book. We’ll also need to read the book all over again to make sure the printer didn’t create a typo elsewhere in the book while fixing the original mistakes.

An Insert-Editable (Padded) ProRes File:

Now, let’s extend the book analogy to a Padded ProRes file. In this book, the words are the same as the previous book, but each chapter of the book is 50 pages, regardless of whether the words fill only 2 pages or all 50 in the chapter. As you read the book, you ignore the blank pages that don’t have any words on them. The book’s table of contents tells us on which page the words of each chapter begin and which page the words of the chapter end. If there’s a typo or a missing paragraph in the chapter, you can print or delete words directly into the chapter without throwing out the whole book. Then, you can proofread just the new words because you know the rest of the book is perfect.

Like our book example, a file is a continuous stream of different types of data (metadata, audio, video, ancillary data etc) laid end-to-end in a standardized pattern inside a standardized container. The pattern depends mainly on the container, but also whether it’s I-frame or LongGOP.

In order to find each data type easily, the container has an index of pointers or “addresses”, typically referred to as “offsets” from a reference point, that allow the decoder to find the beginning of each item, eg a frame of video.  Another index tells the decoder how long the stretch of data is that makes up that frame.

Typically, the addresses are sequential and only as far apart as is necessary for the actual encoded frame of video.  This is ok as long as you don’t need to go back and replace any short stretch of data with a long stretch of data.

If it’s a requirement to go back and replace one frame of video with a different frame of video that is not exactly the same size, then an allowance needs to be made in every address (or offset) for the largest possible stretch of data that might needed to go in a certain order.

Because the decoder (any player) is using addresses and data lengths, it doesn’t know or care if there is padding in the file. Just like our book analogy the Blank Pages (Padding) are ignored when the Book (File) is read.

Adding padding just means that rather than starting the next frame immediately after the current frame’s data ends, the next frame starts slightly later and at a regular interval so that any frame’s data can replace any other frame’s data.