We get lots of questions about the inner workings of our file-based insert video editing feature. In particular, how and why we create insert-editable ProRes files. Read on to find out more.
It may be difficult to understand what Padded ProRes are and why we need them. We like to use the analogy of a book to explain this.
In our analogy:
- The book is a file
- The words on the pages are ProRes encode of content
- The chapters of the book are the frames of ProRes
- The table of contents is the file wrapper
- The binding process is exporting a file
- And the blank pages are the padding
A Standard ProRes File:
Imagine that a standard ProRes file in video editing is a book that you have written.
All chapters are of different length and have a different number of pages and words in them. Each chapter starts where the previous one ends. The book’s table of contents tells us which page we need to go to if we want to find chapter 23, for instance.
In case you notice a typo or want to add a new paragraph to a chapter, you can’t use the old version anymore. You need to throw it out, edit the text, tweak the table of contents, and print all the pages again. Then, you rebind it into a brand-new book.
Fixing the mistakes may also have caused new errors or formatting issues. So, you’ll likely need to read the whole book all over again to check for those.
An Insert-Editable (Padded) ProRes File:
Now, let’s extend our book analogy to a padded ProRes file in video editing. This book has the same amount of words as the previous one. The difference is that each chapter of the book is 50 pages long. That is regardless of whether the words fill only 2 pages or all the 50 of them 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 you on which page each chapter begins and on which it ends. If there’s a typo or a missing paragraph in the chapter, you don’t need to throw out the entire book. Instead, you can edit and replace only that one specific chapter. Then, you can proofread only the text that you made changes to. You know that there are no issues with the rest of the book.
Like the book in our analogy, a file is a continuous stream of different types of data. That includes metadata, audio, video, ancillary data, and more. It’s laid end-to-end in a standardized pattern inside a standardized container. The pattern depends on the container and the type of video compression used (I-frame or Long GOP).
To find each data type, the container uses an index of pointers or “addresses” from a reference point. Many also call them “offsets”. They allow the decoder to find the beginning of each item such as a video frame. Another index tells the decoder how long the stretch of data is that makes up that frame.
Usually, the addresses are sequential. They are only as far apart as it is necessary for the encoded video frame. This is OK as long as you don’t need to replace a stretch of data with another of a different length.
Nonetheless, you may need to go back and replace a video frame with another that is not exactly the same size. You’ll have to make sure that it fits into the video in exactly the same way as the old video frame. But you can’t achieve that if the frames aren’t the same size. So, you should make an allowance in every address for the largest possible stretch of data.
The decoder, which can be any video player, is using addresses and data lengths. Because of that, it doesn’t know or care if there is padding in the file. Same as in our book analogy, you would simply ignore the blank pages (the padding) when reading the book.
With padding, the next frame won’t start immediately after the current one ends. Instead, it will start slightly later and at a regular interval. As a result, any frame’s data can seamlessly replace any other frame’s data.