Drastic's Net-X-Code system includes a partial file restore system, that is available as a standalone server system. The partial file restore system includes indexing, restoration with minimum source access, proxy file generation, thumbnail generation, proxy/primary file playback, metadata extraction and an HTTP/RESTful API. Drastic's PFR supports slow/nearline storage, traditional tape, LTO/LTFS, CXFS, HTTP(S), FTP and cloud based file access. Only the requested audio, video, captions and metadata are accessed from the source file. They are used to wrap into a new local file with minimal access to the storage to allow the fastest and lowest cost restoration or original material possible. Net-X-Code works directly with your original file formats, no mezzanine file is needed.
Net-X-Code Partial File Restore
Net-X-Code's partial file restore provides a complete, index/proxy/metadata/restore capability for Windows, Linux and OS-X.
Net-X-Code uses a real time index system to quickly produce small, pointer files that track the actual media within almost any broadcast or post media file. This file is small enough to keep on fast, local or network storage, and alleviates the need to look at the source file tables/metadata/extra data. When the part of the file that needs to be restored is determined, from timecode or absolute time code, the index file can be used to read only the parts of the file needed to create the new partial file.
Source Files and Proxies
The restoration system includes support for MXF, GXF, LXF, MOV, AVI, DPX, CINE, RMF, VFW, CDX, and all other files supported by Drastic's software (for a full list, please see file format support for www.drasticpreview.com). Along with indexing, the system can produce proxy files with matching metadata and timecode. The proxy files can be read with standard preview players (QuickTime, Windows Media Player, VLC, etc) and Drastic players that work on all major platforms and/or run with timecode across a custom HTML5 web player. The timecode in the proxy can be used to create in and out points to be used on the main source files.
Cloud, SMB, NFS, NAS, HTTP, FTP and SAN Support
The offline/nearline source files can be accessed via a number of access methods. One of the main methods is via the cloud, including FTP and HTTP direct access. Shared file systems like SMB/CIFS, mapped HTTP and NFS files are also accessed directly. SAN or attached storage can be any OS available drive. SGI's CXFS is particularly supported, including automatic access to the DMF tape file and restore API.
HTTP/RESTful API, Single or Multi Server Configs
Restore groups can be contained on one or more servers. Each daemon process can run independently or as a group on a server. The central server process exports an HTTP RESTful/AJAX interface that can be used from within a web browser, or be controlled by user API code in any programming language that supports HTTP get and XML.
FastClip is a system in PFR and Net-X-Code that allows clipping of files and live streams for direct output to web servers. This allows extremely fast turnaround of video assets to external servers or even full resolution assets to be created for immediate use in editing or on-air run down. Because everything is based on timecode and index files, different level/bitrate files can be clipped simultaneously to create multi bit rate video for multiple devices and bandwidth devices.
To make the system more complete, a number of accessory functions are also available:
- Thumbnail generation
- Metadata extraction
- Closed Caption extraction
- Wave/Audio extraction
The partial file restore begins with a source file. Almost any broadcast, post production or web based file is supported (for a full list, see the file format list in videoQC). A RTIndex is created from the original file. This small pointer file is very quick to create and allows fast direct access to the media in the source file. This file can be stored on a local drive, NAS or on the tape/cloud. A secondary process can, at the same time, create a frame for frame matching proxy file with matching metadata and timecode. These files are normally moved to a web facing database server. The file can be played back via HTML5 video with timecode, or many other players. The primary file is then moved off to tape, nas, cloud, aws or other long term storage. When a section of a file is needed, the proxy file can be used to determine the in and out timecode of the segment. These timecode points are then used to reference the original file. That section of the file can then be used to create a new file, either with no conversion (re-wrap) or converting it to another standard format. Only the minimum data required is actually read from the source file. With SAN systems like CXFS, the required bytes are automatically recalled to make the system even more efficient.