1 Introduction

This chapter describes an overview of the Oracle DIVArchive Avid Connectivity and includes the following information:

Oracle DIVArchive Avid Connectivity Overview

The purpose of Oracle DIVArchive Avid Connectivity with the Oracle DIVArchive Suite is transferring archival data to and from Oracle DIVArchive in specific video formats, specifically GXF (General Exchange Format) and MXF (Material Exchange Format), and to enable archiving and retrieving single clips, or a sequence of clips. The Avid Media Services manages all requests submitted by the Avid GUI (Interplay Access or Media Composer). See Appendix B for information on Avid and DIVArchive compatibility support.

The AMC (Archive Manager Communicator) and TMC (Transfer Manager Communicator) related components are not installed with the main DIVArchive installation, and is a separate installation process. You can install two different packages as follows:

  • 1.0 for Legacy Workflows

  • 2.0 for AVID Direct ISIS (an Avid Storage System) connectivity

Additional installation is also required for certain plugins for both AMC and TMC. This document describes the installation, configuration, and operation of all Avid components.

The following figure represents the overall workflows for Avid Connectivity in each instance:

Avid Connectivity Workflow Overview

AvidForDIVArchive and DIVArchive Release Compatibility

Avid Interplay is compatible with the following DIVArchive releases:

  • AvidForDIVArchive release 1.x is compatible with DIVArchive releases 6.5.3 and later.

  • AvidForDIVArchive release 2.x (for direct ISIS) is compatible with DIVArchive releases 7.2.1 and later.

See Appendix B for additional information on Avid Interplay and AvidForDIVArchive release compatibility.

AMC (AM Communicator) Overview

The AM Communicator (AMC) enables interaction between the Avid Archive Manager solution and DIVArchive. AMC receives Push, Pull, and Remove requests from the Archive Manager and translates them into DIVArchive API calls.

Legacy AM Communicator

AMC transfers data from DIVArchive to the DMS (Distributed Media Service) Archive/Restore Service and vice-versa.

AM Communicator is based on the following:

  • AMC is currently only implemented in Windows Environments.

  • DIVArchive 7.1 and later does not support complex object processing with Avid AMC. However, Avid AMC customers may decide to employ complex object processing for Source/Destinations other than Avid AMC.

  • Supports the following types of requests initiated by the Avid Archive Manager:

    • Archive (Push)

    • Restore and Oracle Partial File Restore (Pull)

    • Delete (Remove)

  • Processes multiple requests simultaneously. You configure simultaneous request in the amc.conf file.

  • Supports Unicode file, clip, and sequence names.

  • Media received from the Avid DMS Archive is stored as a DIVArchive object. AMC operates in three different modes:

    • Metadata and media files pertaining to a received clip, or sequence, are stored individually (single file per object).

    • Metadata and media files pertaining to a received clip, or sequence, are stored as one or more DIVArchive objects containing multiple files (multiple files per object).

    • A special mode migrates objects from single file per object mode to multiple files per object mode. See Appendix A for Oracle DIVArchive options and licensing information.

  • You define the destination tape group or disk array for Archive requests using the partition parameter value in the archive profile. This value enables archiving media to different tape groups and disk arrays without requiring you to reconfigure and restart AMC.

  • You can setup a configuration where the partition parameter value from the archive profile is used as the DIVArchive Source/Destination Name and the destination tape group or disk array is specified in AMC configuration file.

The following figure demonstrates the standard workflow for AMC Push request (archive) processing. See Chapter 4 for details on Legacy AMC Workflows.

AMC Push Request Processing Workflow

Direct ISIS Connectivity AM Communicator

Using Direct ISIS Connectivity, data is directly read from, and written to, the ISIS server by the Oracle DIVArchive Actor using an AVID_DIRECT Source/Destination Type. AVID_DIRECT is built on top of the CIFS protocol, and has similar access mechanisms. Therefore Direct ISIS only works with AVID_DIRECT Source/Destination Types.

Note:

Linux-based Actors do not support UNC paths for CIFS sources and destinations.

You must install and configure the ISIS Client on each Actor that reads to, and writes from, the ISIS server; otherwise, the Actor cannot access the ISIS Server. The configuration must match the Archive Provider (AP) configuration, and the AVID_DIRECT Source/Destination must be configured with proper authentication for the ISIS server.

All Restore requests from Avid are converted into Oracle DIVArchive Partial File Restores (see Appendix A for Oracle DIVArchive options and licensing information). Therefore, AMC never submits full Restore requests to the Oracle DIVArchive Manager, because Actor requires the complete ISIS path for files. If full restore is required, Avid sends a Partial File Restore request with [Begin, End] to accommodate the full path requirement.

Metadata files (.AAF) are archived as part of the object (like in Legacy Mode) if the Allow Metadata Archive value is set to Yes. You configure this value in the Archive Manager under Interplay Administrator, Site Settings, and then Asset Tracking/Archive Settings.

you can increase throughput using dedicated network adapter cards. Oracle recommends Intel Pro for 1 Gbps, and Myricom for 10 Gbps, for the ISIS server interface on the Actor computers. You can increase overall throughput by increasing the number of Actors (see Appendix A for Oracle DIVArchive options and licensing information), and is limited only by the ISIS server bandwidth. The number of simultaneous requests you can submit by Avid are greatly increased (this value is configurable in amc.conf; the default setting is 100) because AMC and fpdiDET2 are only processing commands.

  • Data flows through a single path using Avid Direct Mode compared to the multiple paths used by a legacy configuration so there are no data bottlenecks.

  • The Actor reads and writes data to the ISIS server through the ISIS Client rather than the legacy's fpdiDET2 (AP - Archive Provider).

  • All features of the legacy workflows are retained except the data path.

  • One Direct ISIS AMC can handle up to 10 Legacy AMC jobs.

  • One AMC, and one Backup AMC, are enough per site.

  • You can install AMC on any computer, and AMC does not need to be on an Actor or archive provider computer (for example, a Manager computer).

  • ISIS Clients installed on all Actors interfacing with ISIS should have separate network adapter card cards to obtain the best throughput.

  • All objects archived using Legacy AMC are compatible with both the new AMC, and fpdiDET2.

The following figure demonstrates the standard workflow for AM Communicator Push request (Archive) processing using Direct ISIS Connectivity. See Chapter 5 for detailed information about Direct ISIS connectivity and configuration.

AMC Push Processing for ISIS

TMC (TM Communicator) Overview

The purpose of the TMC (TM Communicator) to DIVArchive interface is to enable archiving of media from the Avid Unity system to DIVArchive, and restoring archived media from DIVArchive to Avid Unity through the Avid Transfer Manager (renamed to Avid Transfer Engine in Interplay environments).

TM Communicator is partially or fully supported with Interplay release 3.3 through release 3.8. See Appendix A for DIVArchive options and licensing information, and Appendix B for compatibility information.

TM Communicator is based on the following:

  • You initiate DHM (Data Handling Module) and DET (Dynamically Extensible Transfer) Archive requests from the editing station using Avid Media Manager, Media Composer, or other Avid editing application Send to Playback and Send to Workgroup commands, or corresponding TMC Automatic API calls.

  • You initiate DHM and DET Restore requests using the DIVArchive Control GUI Restore command, or the corresponding DIVArchive API call.

  • Media received from Avid Unity is stored as DIVArchive Objects. In the DHM workflow, each of these objects contains a single GXF or MXF file, depending on the configuration. In the DET workflow, each object contains all media files pertaining to the received clip, or sequence, along with corresponding Metadata files.

  • The DET workflow in TM Communicator supports archiving and restoring of both individual clips and sequences.

  • The DHM workflow in TM Communicator supports restoring and archiving media wrapped in GXF and MXF.

    TM Communicator can handle GXF and MXF clips that contain DV, DV-25, DV-50, D10 (30, 40, and 50 Mbps essences), and PAL and NTSC standards.

  • Interplay variants of TM Communicator support archiving and restoring DNxHD, and DV-100 content through DHM. These HD formats can be wrapped only in MXF. The Avid Interplay environment with Transfer Engine 1.2.4 and later is required.

  • TM Communicator supports clips with 24-bit and 16-bit audio tracks. There is also an option to perform 24-bit to 16-bit audio conversion during DHM archive and restore. TMC for Interplay 2.2 and later supports up to 16 audio tracks, while variants for earlier releases support up to 8 audio tracks.

  • TM Communicator preserves an original clip time code during all archive and restore operations.

  • The default format is specified in the configuration as either GXF or MXF and is used when there is no file extension specified. During DHM restore, any file without a GXF or MXF extension is considered to be in the configured default format.

  • TM Communicator is implemented only for Windows because Avid Technology provides only Windows based implementations of their TM Client software and TM Auto API library.

  • TMC does not support Unicode file, clip, and sequence names because Avid does not support Unicode for Transfer Manager, Interplay Transfer Engine, TM Client, and TM Auto API. TMC terminates the request if it finds any Unicode characters in the file, clip, or sequence names.

  • Interplay variants of TM Communicator also support restoring of MXF wrapped XDCAM content using DHM - XDCAM HD422 50 Mbps, and XDCAM SD IMX 50. The Avid Interplay environment with Transfer Engine 1.6 and later is required. Archiving of these formats is not supported because they are not supported by Avid (itself).

  • TM Communicator supports restoring MXF content with stereo Broadcast WAV Audio (BWF). Avid does not support ingest of stereo audio directly; each stereo track is converted into 2 mono audio tracks. No conversion of audio data is performed during this process. Audio data from each sample is read for left channel data and right channel data before being assigned to appropriate mono track data. For example, stereo track 1 = mono track 1, stereo track 2 = mono track 3, 4 and so on).

  • TM Communicator supports DHM archiving of sequences with some clips having only video, or only audio. In other words, it supports holes in video tracks and audio tracks of Avid sequences. This is applicable to both MXF and GXF wrapped files; except for HD formats which are only supported with MXF. The only restriction that you must have all clips of a sequence with the same video and audio formats. Multiple resolutions in the same sequence are not supported.

    This feature is supported for all of the following video and audio formats supported by TMC for DHM archive:

    • Video formats (both PAL & NTSC): DV, DV-25, DV-50, D10 30 Mbps, D10 40 Mbps, D10 50 Mbps, and HD formats DV-100, DNxHD, XDCAM HD422 and SD(IMX), and AVCIntra 100 Mbps.

    • Audio formats (both 16 and 24 bits): PCM & AES3.

  • Interplay variants of TM Communicator support archiving and restoring of MXF wrapped AVCIntra content. The Avid Interplay environment with Transfer Engine 2.2 and later is required.

The figure below demonstrates the TM Communicator Archive Workflow.

TMC Push Workflow

The figure below demonstrates the TM Communicator DHM Restore Workflow.

TMC DHM Restore Workflow

The figure below demonstrates the TM Communicator DET Archive Workflow.

TMC DET Archive Workflow

The figure below demonstrates the TM Communicator DET Restore Workflow.

TMC DET Restore Workflow