Admin Overview

Akomi Description

Akomi is a private web platform that provides a simple and secure way of publishing & sharing video, audio, and other media formats used in digital content creation. Akomi integrates seamlessly with CatDV systems, enabling the secure web distribution of CatDV assets and metadata to large groups of non-production users with minimal setup or administration.

Although Akomi shares many features with Digital Asset Management (DAM) systems, it focuses on simplicity and ease of use over complexity and feature count. If you need all the features of a DAM, you would want to use CatDV Pro to fulfill those needs, however, over many years of DAM system deployment we have found that the vast majority of media consumers/users in a DAM workflow need a few critical features, presented in an easy to use interface that requires little to no training. Akomi is focused on filling this role.

Getting Started with Akomi

This guide assumes you are familiar with the user functions of Akomi. Please consider the Akomi User Guide , which outlines the basic functionality of the system, as a companion to this manual. It should be read carefully before undertaking the administration of an Akomi system. You can also find a link to the Akomi User Guide on the Akomi Help page, in your Akomi system. You may access this page by clicking on “Help” at the top right corner of the Akomi interface.

Akomi Site Sections

Akomi is divided into three main work areas, or sections - the Inbox, the Library and System Administration.

There are no hard and fast rules to determine how to use the Inbox or Library. Choose the section for your media that best fits your workflow. However, the following sections contain suggested use cases for each section of Akomi.

To demonstrate the idea behind the Akomi Inbox, we can use the example of an email application. Email sent to several people typically comes into each person’s inbox where it is read or reviewed. Each user’s inbox is unaffected by the other users, meaning when a message is viewed or archived by one recipient, the message may still be sitting unread in the other recipient’s inbox. Also, typically an email inbox is used for only a few incoming messages and not for long term storage of email (in a perfect world.)

Along the same lines, the Akomi Inbox is designed for short-term review of a few clips, generally these are “cuts” or work in progress.

In contrast to the short-term workflow of the Inbox, think of the Akomi Library in the same way you would think of it’s namesake in the real world, a long-term, large, highly organized collection of assets with advanced search capabilities. The Akomi Library is where you may allow users to search and browse thousands of assets and even download or share a version of the asset to others, if desired.

Let’s take a deeper look at each section and how each might fit into a video workflow in the next section.

The Inbox

The Inbox in Akomi was designed to display a limited number of clips. It is intended for short term access to work in progress (WIP), such as an edited video or “cut”, for review and approval. As such, it features the simplest interface.

A typical Inbox workflow is for a user to log in and view their Inbox to see the latest published versions of a work in progress. The assets would only remain there for a short time, and thus the asset count would remain low (maybe half a dozen to one hundred assets per Media Group). For this reason, the search and sort options are limited in the Inbox.

As the Inbox is meant to be a temporary workspace for viewing a relatively small number of assets. Its features are focused on review and approval. If enabled, the Action Buttons allow a user to “Approve”, “Reject”, or “Archive” an asset. Each of these buttons hides the clip from view in the user’s Inbox. The Approve/Reject buttons also write a status into the Approval Log Report and also report that status back to the CatDV Server where other workflows may be triggered by the metadata change. The “Archive” Button allows users to hide an asset from their Inbox without recording a status.

None of these actions deletes the asset from the system. Other users may still view the asset in their Inboxes. As mentioned above, this is similar to an email inbox where you would review an email and then archive it to a folder for long term storage without affecting any other recipient’s email inbox.

Note: The Inbox Archive button has nothing to do with video archiving, it is merely archiving the clip record from your Inbox and has no effect on the media. The reason for this seemingly confusing choice of terms is that the typical non-production Akomi user will likely be more familiar with email archives than with archiving video media and so this should present little conflict or confusion.

The Library

Once an asset is approved or finished, the final version might be published into the Library for long term access where thousands of assets could be searched or browsed. Like the physical building for which it is named, this idea of an easy to access repository of a large number of assets best describes the Akomi Library. You will note that the Library has advanced search and sorting options as well as many workflow enhancements focused on asset distribution & sharing, such as “Playlists”, where a group of assets can be gathered and shared for review or re-use by a user.

Whereas an organization might have a few dozen to few hundred assets in the Inbox, the Library typically retains asset records long term and so might grow to contain tens of thousands of items. Hence it’s enhanced search, sort and sharing tools.

When to Use the Inbox and When the Library

The Inbox and Library may be used separately, but they are most typically used together as part of a larger workflow. The data path is designed to flow from work-in-progress state (Inbox) where several progressively more polished versions of an asset might be viewed, to a finished, approved version of the asset (Library) collecting input and metadata updates from users along the way.

From a casual glance, the sections are indeed very similar in base functionality as they both display assets and have many features in common. As you learn more about the feature set and organization of Akomi, the differences will become more clear. When first planning your workflow, consider the asset count, security and organization needs and intended use of the assets and choose the appropriate section based on these variables.

Also know that should you decide to move a workflow and its assets from one section to another, this is fairly easily accomplished in the early days/weeks of a deployment when file counts are low. We recommend you plan your asset metadata / organizational schema and then run a few test scenarios with demo material (CatDV & Akomi’s connected automation make this quick and easy) and you will quickly come to see how each section may be used in your workflow. Your system integrator should be able to assist with this process and outline several proposed workflows as well.

System Administration

The System Administration area is somewhat self explanatory. It is where all system settings, permissions, and reports are managed and is only available to administrators and managers. It is accessed through the link at the top right of the Akomi window. Your integrator will assist you with setting up your system and training you on how the system, users and permissions are managed. More in-depth information on system information is available in the Feature Description (#coming soon), and Reference Guide sections.

Akomi Configuration Introduction

General Information

VM/Hardware Info

Akomi runs in a Linux Virtual Machine (VM). The VM can run on OS X, Windows or Linux host with VirtualBox, or VMWare ESXi. These can be hosted locally, on in-house hardware, in an off-site data center, or on a cloud platform.

The Akomi VM is commonly deployed on the same system as CatDV Server, or it may be installed on separate server hardware.

The Akomi VM is given it’s own IP address and is licensed to the host hardware as well as the system URL. Akomi maintains its own database (This db runs on the VM but backed up to your chosen location) as well as its own copy of the proxy, mezzanine and thumbnail media. This media is stored either on drives directly attached to the VM host, or on a mounted share, (provided that the storage device has sufficient bandwidth to provide reliable throughput for your needs.) North Shore Automation generally recommends direct attached drives or raid arrays in order to maximize system simplicity and reliability.

You may access more detailed hardware information at this link:

Akomi Server Minimum Requirements Info

The following are some minimum VM host hardware examples for quick reference:

Apple Mac Mini with direct attached Thunderbolt SATA drive for media, same size or larger, direct attached USB 3.0 drive for media backup

Windows Workstation or Server with internal SATA drive for media, same size or larger, USB 3.0 drive for media backup

Linux Server with internal SATA drive for media, with a USB 3.0 drive of the same size or larger, for media backup

Note that these are minimum configurations. You may scale hardware to match your needs and Akomi can run on enterprise server hardware or a variety of cloud platforms as well. Your reseller/system integrator can assist with matching a hardware solution to your needs and can offer you several levels of hardware solutions.

Bandwidth Needs

North Shore recommends that you choose your proxy format to balance your quality needs to your available bandwidth and estimated user count. A general rule of thumb is divide your bandwidth upload capacity in half to get your maximum user count. (ex. a 100Mb upload connection could easily serve 50 concurrent users.) This will vary as you change the bitrate of your proxy files. NSA generally recommends proxy files in the 700k to 1.5Mb range, depending on bandwidth available and quality needs. Discuss this with your integrator or North Shore support if you need assistance.

Proxy/Data Storage Needs

Once you have decided on a proxy format, you may calculate your storage needs. Generally, using a 1 Mb per second proxy format, we recommend 1 GB per hour of video footage. This is conservative, but a good guideline. Therefore you could fit 4,000 hours of proxy video on a 4TB drive. (1 TB = 1,000 hours) If you plan to store alternate versions of your assets for download, then you should allow for more space and create some test files in the chosen formats to aid you in estimating your storage needs.

Akomi Topology Overview

This is an overview of the basics of deploying an Akomi system in a network environment with external access enabled. It is in no way intended to be a guide for your specific deployment, rather a starting point for discussion. Please engage with North Shore Automation support engineers to approve your design before proceeding with any network configuration changes.

Typically clients deploy the server internally with external access disabled for testing while the IT infrastructure is reviewed.

Server Overview

Akomi is a private web platform that provides a simple and secure way of publishing & sharing video, audio, and other media formats used in digital content creation. Akomi integrates seamlessly with CatDV systems, enabling the secure web distribution of CatDV assets and metadata to large groups of non-production users with minimal setup or administration.

Akomi runs in a Linux Virtual Machine (VM). The VM can run on an OS X, Windows, Linux or ESXi server, which may be hosted locally on in-house hardware, in an off-site data center, or on a cloud platform.

The Akomi server typically runs its own MySQL database (This db runs on the VM but backed up to your chosen location) as well as its own copy of the proxy, mezzanine and thumbnail media. As this article is focused on the network topology surrounding an Akomi deployment, more information on the storage of Akomi data is discussed in detail in the North Shore Knowledge Base located at http://kb.northshoreautomation.com.

Akomi uses the following technology stack:

For specific versions, please contact North Shore Automation support or check the release notes at http://kb.northshoreautomation.com/akomi-portal/akomi-release-notes.

Additionally, if Akomi is deployed with a host DAM (CatDV) the following protocols may be used for communication and data delivery to Akomi (protocols dependent on your specific deployment, contact your support engineers for exact connection types):

Port Information

Akomi is accessed via web browser over HTTP or HTTPS. NSA recommends HTTPS and the installation of a valid SSL certificate.

To publish an asset, CatDV Pro sends a data package to Akomi consisting of an XML file (metadata) and one or more media files (typically mp4 media and/or a jpg thumbnail.) These files are delivered to the Akomi Import folder via SFTP, or mounted network share (SMB or AFP depending on client choice.)

If enabled, Akomi writes back metadata changes to the host DAM (CatDV) via either SSH or REST calls (dependent on your CatDV system configuration.) REST is preferred by North Shore.

The complete preferred port listing for these workflows is as follows:

Akomi Server

CatDV Server/Worker Node

Shared Storage Server (if applicable)

* In deployments where Akomi is hosted off-site the CatDV REST and SSH ports must be open for the Akomi server to connect if metadata write-back is enabled. These can be restricted using firewall rules to prevent access from any other IP addresses.

** If Akomi is hosted off-site and using CatDV REST API for metadata writeback, North Shore recommends the installation of an SSL certificate on the CatDV Tomcat server.

Deployment Example Drawings

In smaller environments the Akomi VM is commonly deployed on the same system as CatDV Server.

In more robust environments it may be installed on separate server hardware or in an off-site environment. (Private data center, Amazon, Rackspace, etc.)

In either case, the following diagrams offer insight into basic topologies and data paths for the system components.

Click to enlarge the drawings

Akomi Basic Topology - OS X

Akomi Basic Topology - Linux/Windows/ESXi

Akomi Network Topology

Akomi Application Topology

Akomi/CatDV Topology

Akomi Application Topology - Reverse Proxy A

Akomi Application Topology - Reverse Proxy B