Document toolboxDocument toolbox

Vidispine

VidiCore 5.3 under the hood

Owned by Sofie Almberg (Deactivated)
Last updated: Feb 09, 2021 by Niklas Vernersson (Unlicensed)
5 min read

Vidispine Server, Vidispine API, VaaS are now all called VidiCore. The packages and names in documentation will change during the second half of 2020. Consequently, VSA and VMA now stand for VidiCore Server Agent and VidiCore Management Agent. 

With the latest update 5.3, we enabled several interesting new features that we would like to share with you in more detail. As you know, there is always a story behind any feature – a story about a real-world market development or an ongoing customer journey.  

Well, not entirely true – at Vidispine, we also predict new market requirements and the appliance of emerging technologies in the future to come. But anyway. 


The stories we would like to share with you in this episode of VidiCore 5.3 are 

  • HEVC support 

  • Photon IMF support 

  • Support for import of DASH packages  

  • Shape deduction/analysis on files/packages not imported yet 

  • Migrate bulky metadata from database to storage  

Isak Jonsson, CTO and co-founder of Vidispine and head of the development strategy, gives us a background on some of the new features found in the latest 5.3 release of VidiCore. 


First of all, HEVC support, why is this important?   

  • Well, you have to remember that VidiCore is a media manager. We do not have to or need to transcode all files that enter the Vidispine media supply chain. For our customers, it is equally important to manage media files in the VidiCore media supply chain. A decode of HEVC files means that we can extract all necessary metadata from the media file and conform this metadata in our VidiCore database together with metadata collected from all the rest of the services in VidiNet. Of course, the new decode also enables a new transcode workflow for cloud proxy editing and distribution using a more common codec such as H264 (AVC) – still the by far most used media codec on the market. The industry-leading Bitmovin encoder for AWS in VidiNet handles other HEVC codec requirements for OTT distribution. 

The next topic is the IMF support in VidiCore 5.3. The IMF format can be described as a standardized mobile video project folder containing all media-related components such as audio and video clips, subtitles and licensing specifications according to an edit list inside the IMF package. The main reason and advantage of the IMF is that you can deliver one package specifying many program versions. 


Photon support for IMF in VidiCore 5.3, can you explain what this is all about?   

  • Although being a standard, some content creators have different interpretations of the IMF standard. This can cause problems. Because of this, Netflix released an open-source tool called Photon to verify IMF packages to comply with the Netflix specification. Many other prominent vendors have decided to follow this standard. Because of this, VidiCore and VidiCoder are now able to use this tool to quality control any incoming IMF package for compliance with the Netflix standard specification of IMF. If there are any issues, VidiCore will present a report and take any automated action configured in the Vidispine media supply chain.  

This reminds us a bit of the MXF Op1a specification interpreted differently between some vendors back in the days. Finally, the industry seemed to mostly unite around the Sony interpretation and definition of MXF OP1a, referred to as XDcam.MXF. 

The first standardized version 1.0 of IMF was released on 19/2 2011. Today, IMF delivery is being widely adapted and used as a distribution format between big media platforms such as Netflix, HBO, FOX and many similar broadcasters and VOD delivery services.  

Many solutions are generating OTT packages such as HLS, DASH and MSS – but we do not see many solutions that actually import the same package for media managing. In the 5.3 version of VidiCore, we are now introducing support for importing DASH packages. 


Can you explain why the import of DASH packaged is important for media management? 

  • The DASH import support is a feature developed as a result of many different customer requests. We primarily needed DASH support as a single item in our system - not as a folder with thousands of fragments. For example, a DASH file created by our service partner Bitmovin needs to be managed and archived in the Vidispine MAM system – this is the story here. Of course, decode support of a DASH file also enables several new possible transcode workflows, which is always good.  


There is a relatively long description of a feature – the “Shape deduction/analysis on files/packages not imported yet”? 

  •  “Shape deduction/analysis on files/packages not imported yet” is a perfect example of common workflow challenges solved by Vidispine. Everyday media files are sent between companies and organizations, and it is not uncommon that a file that does not meet the expected technical specifications on the receiver side. This results in a full file ingest of sometimes very big files - just to find out afterward that the file did not meet the specifications. Uploading and ingesting big media files like this takes up unnecessary space, time and resources. What if we could just read out the media file's metadata header information before we upload all this video data? With this new feature, Vidispine, users can now build ingest solutions to detect and verify media specifications before uploading and ingesting.  

Yes, there you are – the “Shape deduction/analysis on files/packages not imported yet” feature is here. And a great name too.  


We have one last thing - a feature referring to “bulky metadata”. What is that?  

  • “ Bulky metadata “ is the Vidispine wording for temporal metadata such as audio waveforms, cognitive metadata over time such as speech to text, objects, environments, labels and similar image recognition metadata. Vidispine is at the forefront of cognitive metadata-driven media supply chains, and we recognized the need for being able to target new storage areas for this kind of metadata that will grow very fast to huge sizes. Being able to store there on object storage or file systems instead of your RDMS makes it possible to scale much higher. This is just one of many examples of how Vidispine continuously optimizes the media supply chain, Isak concludes. 


We hope all or some of these background stories by Isak Jonsson, CTO, have given you some ideas on how to improve and continue developing your current media supply chains. Do not hesitate to contact our team to discuss any thoughts or ideas for the future.  

We are here for you.  

 

Related articles