Traditional asset management systems can handle many images and files at a time, but what happens when you start incorporating video files that are 1000s of times larger than the largest asset in your current system?
Before we delve into this topic, let’s put some context around it, by looking at something we can all relate to. Let’s see what the file sizes are of videos captured from a typical smartphone, which many of us use on a daily basis:
- An uncompressed 8-bit frame could require about 25 MB of storage
- An uncompressed 16-bit frame could require about 50 MB of storage
- An uncompressed 4K 1 minute long clip could require over 40 GB of storage
After videos are edited, their resolutions become even higher – a five minute clip could require over 500 GB of storage, which can be 3,000 times the size of a massive still image. Some asset management systems may not be able to accommodate many files of this size, and could quickly max out of storage. This could lead to interruptions and slow down in company projects while IT updates the systems.
So now that we understand more about this challenge, what are some of the ways we can alleviate it? Or better yet, prevent it from occurring altogether?
This is where I want to introduce a solution, which is unique to Evolphin Zoom’s media asset management system, called front-end de-duplication. Front-end de-duplication is the process of only storing the incremental changes to video files. Take a look at the diagram below:
Suppose I take a video on my phone that’s 100MB, and save it into storage. In the diagram, that’s represented by the 100MB blue base of each column. I then go into Adobe Premiere, AfterEffects, and other video editing tools to make changes to my files. Each time I make revisions and save a new version of my video file, my file is getting larger; as depicted in the first column, a brand new larger copy of the revised video is saved into storage every time. This reflects how traditional asset management systems store files.
Now let’s take a look at the second column. With front-end de-duplication, the system is smart enough to identify that although I am making edits, the base video has not changed, and therefore only stores the incremental changes that I have made on top of the original video.
After completing my edits, what could have originally taken 580MB of storage will now only take up 110.5MB. This method of front-end de-duplication can be the key to taking up less storage space to prevent overrunning your systems’ capacity, especially in video post-production organizations.
In my next post, I will go over another typical challenge of managing large videos, and go over some tips on how to more effectively set up a system where many users can simultaneously view and edit large videos without worrying about interferences in streaming, so stay tuned!