The off-the-shelf web application provided by Kaltura to manage content, collect analytics, publish content, create custom players, set access controls, etc. is called a Kaltura Management Console (KMC, for short). A major question for any enterprise using Kaltura is: How many KMCs do we need? The answer is: Just enough, and not one more.
It is very difficult to share content between KMCs, and so there is a major incentive to have the smallest number of KMCs, perhaps only a single one. However, it is also difficult to "hide" content from others who are sharing the same KMC, and that can cause concerns about privacy, access control, and inadvertent use (or mis-use) of content. In my mind giving someone an account on a KMC is like giving someone root access on a UNIX machine.
The solution we used at the U-M was to deploy two KMCs for now. One is for two types of content: video which is generally available to the public, such as promotional materials, and video which is used in courses via our local Sakai implementation, CTools. We provisioned a second KMC for ICPSR to use for its content, which falls more into the "research data" category. This content will require signed agreements for access.
Once Kaltura provisioned our KMC I performed a few initial house-keeping chores:
- Created accounts (Authorized KMC Users) for my colleagues on the project. Each has a Publisher Administrator role. (Administration tab in the Falcon release of the KMC.)
- Changed the Default Access Control Profile to require a Kaltura Session (KS) token. All content managed by this KMC should require a KS token by the player. (Settings - Access Control tab)
- Created a new Access Control Profile (called Open) which does not require KS. I don't know if I will need this, but want to have a more open profile available.
- Changed the Default Transcoding Flavors to (only) "Source." Our content has already been transcoded, and so we don't need to pay for the time and storage for additional flavors such as HD, Editable, iPad, Mobile, etc. (Settings - Transcoding Settings)
- Created a Custom Data Schema to hold the extensive descriptive metadata that accompanies the content generated in our project (MET Extension). This step is extraordinarily tedious since it has to be done field-by-field through a web GUI. I can download a copy of the schema I created in XSD format; wish I could upload one to create it. (Settings - Custom Data)
- Created a slightly customized player for use with our content. Wanted to size it to fit our content, remove the Download button, etc. This is super easy. (Studio tab)
- Created a Category which we will use to "tag" our content. (In this case I created one called MET-Ext.) This is mostly useful for searching and browsing within the KMC interface. (Content - Categories tab)
- Uploaded a few videos and set a few of the metadata fields. (Content - Entries)
- Put in a request to our account manager to enable a locally hosted Drop Folder. This is a mechanism whereby we create a local "fetch" location where an automated Kaltura job can pull content and ingest it. While one would think that this is a common mechanism for submitting content, the process is slow and poorly documented, and cannot be managed via the KMC. I'll post more details about the process once I have a working Drop Folder in place.
- Created the local infrastructure for the Drop Folder which is really just identifying a machine to play host, and then creating an account Kaltura can use.
These steps got us to the point where we could start putting Media RSS files containing the metadata and pointers to the video into our Drop Folder for ingest into Kaltura.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.