Version 3 (modified by robert, 3 years ago)

--

Contents

  • Introduction
  • Asset, media file and metadata
  • What has to be uploaded?
  • The metadata file

o Simple Dublin Core
o Qualified Dublin Core

  • The video upload file

o Structure and elements
o Actions and related elements

Introduction

MediaMosa is a solid, flexible and scalable media distribution platform. It is the foundation of several succesful video services developed by SURFnet and Stichting Kennisnet, to the benefit of (the field of) education in the Netherlands. MediaMosa was published under an open source licence in the middle of 2009 by both organizations, and by software developer Madcap.

MediaMosa is able to store and playback video on demand. Video files are stored in a repository and played back by streaming servers. The functionality in MediaMosa to upload media files is split into two components. The Batch Upload component allows registered MediaMosa users to upload multiple files to MediaMosa simultaneously using FTP. EGA's (End User Applications) and EGA end users can use the File Upload component. This document aims at the end user who wants to upload media files via FTP, and focuses on the requirements at which the metadata has to meet.

Asset, media file and metadata

A central object in the organization of content within MediaMosa is the so called asset, which can be considered a unit of content. An asset mainly consists of one or more media files (video, video stills) and metadata that describes the asset. In MediaMosa a media file is always part of one single asset, but an asset can contain multiple media files. If it does, these files are versions of the same media clip in different file formats, bit rates or resolutions.

The metadata records information about the properties of an asset, concerning the content of the media file (title, language, publisher, etc.), or the technical properties (file format, resolution, bitrate, etc.). Technical metadata is automatically determined by MediaMosa while analyzing the uploaded media file.

What has to be uploaded?

To upload an asset, three files are mandatory:

  1. the media file(s) (e.g. video.wmv),
  2. a metadata file that describes the media file in XML, using the Dublin Core Metadata Element Set,
  3. a video upload file (.vuf), laying down the upload procedure in a XML format.

The video upload file contains references to the media and metadata files. Therefore these media and metadata files should have been uploaded before MediaMosa can upload the video upload file.

The metadata file

MediaMosa uses the Dublin Core Metadata Element Set (DCMES) to describe the media file in XML. The Dublin Core standard includes two levels: Simple and Qualified. Simple Dublin Core contains fifteen elements; Qualified Dublin Core includes three additional elements, as well as a group of element refinements. A refined element (or qualifier) shares the meaning of the unqualified element, but with a more specific scope. Simple Dublin Core

The Simple or unqualified Dublin Core Metadata Element Set consists of 15 metadata elements:

  • dc:title
  • dc:creator
  • dc:subject
  • dc:description
  • dc:publisher
  • dc:contributor
  • dc:date
  • dc:type
  • dc:format
  • dc:identifier
  • dc:source
  • dc:language
  • dc:relation
  • dc:coverage
  • dc:rights

A comprehensive explanation of these 15 elements can be found at:  http://dublincore.org/documents/dces/

The Dublin Core XML schema can be found at:  http://www.openarchives.org/OAI/2.0/oai_dc.xsd

Qualified Dublin Core

MediaMosa doesn't support the complete Qualified Dublin Core, but only a selection which contains the next qualifiers:

  • dcterms:alternative
  • dcterms:abstract
  • dcterms:created
  • dcterms:issued
  • dcterms:spatial
  • dcterms:temporal
  • dcterms:hasFormat
  • dcterms:isFormatOf
  • dcterms:medium
  • dcterms:extent
  • dcterms:license
  • dcterms:rightsHolder
  • dcterms:isReferencedBy
  • dcterms:isPartOf

The meaning and use of these qualifiers is extensively explained at:  http://dublincore.org/documents/usageguide/qualifiers.shtml

The Qualified Dublin Core XML schema can be found at:  http://dublincore.org/schemas/xmls/qdc/dcterms.xsd

The video upload file

The upload procedure is laid down in the Video Upload File (e.g. myvideos.vuf). With the information in this file the media file(s) and metadata will be related to each other and included in MediaMosa. It enables the supplier of media files to save, update or delete media files and metadata in the database. The FTP account defines the account under which the videos will be placed in the database, so this can not be established in the video upload file.

Structure and elements

The video upload file is a XML file with a specific structure and elements: 

<FTPupload> the root element
  <email>[EMAIL ADDRESS]</email> the email adress where upload status messages will be sent to
  <videos> the list of assets that are to be uploaded
    <video> an asset
      <action>[save|update|delete]</action> the action that has to be executed on the media file(s) and/or metadata file
      <referenceId>[STRING]</referenceId> an unique identifier of the asset, created by the uploader
      <metadataFile>[FILENAME]</metadataFile> a reference to the metadata file
      <formats> the list of media files that are to be uploaded
        <format> a media file
          <action>[save|update|delete]</action> the action that has to be executed on the media file
          <external>[URL]</external> a reference to the media file if it is stored outside MediaMosa
          <mediaFile>[FILENAME]</mediaFile> a reference to the media file (if is has to be uploaded to MediaMosa)
          <available>[yes|no]</available> indicates whether the media file has to be visible in the interface or not
          <downloadable>[yes|no]</downloadable> indicates whether the the media file has to downloadable or not
          <createstill>[yes|no]</createstill> indicates whether a video still has to be created or not
          <frametime>[INTEGER]</frametime> the number of seconds after the beginning of the video, indicating the frame of which the still is created
        </format>
      </formats>
    </video>
  </videos>
  <collections> a list of collections in which all of the uploaded media files have to be included
    <collectionId>[STRING]</collectionId> an unique identifier of a collection
  </collections>
  <categories> a list of categories to which all of the uploaded media files have to be related
    <categoryId>[STRING]</categoryId> an unique identifier of a category
  </categories>
  <accessRules> a list of rules that set down which end users are allowed to playback the media files in this upload 
    <accessRule>
      <ruleType>[DOMAIN|REALM|GROUP|APP]</ruleType> one of the four types of user sets
      <ruleValue>[STRING]</ruleValue> the value of the domain (e.g. surfnet.nl), realm (e.g. peter@surfnet.nl), group (e.g. academia.group)
    </accessRule>
  </accessRules>
  <transcodings> a list of transcodings which have to be executed on all of the uploaded media files
    <transcodingName>[TRANSCODING PROFILE]</transcodingName> the name of a transcoding profile laid down before
  </transcodings>
  <recentList>[yes|no]</recentList> indicates whether or not all of the uploaded media files have to be included in a variety of lists on the website
</FTPupload>

Actions and related elements

Depending on which 'action' has to be executed, some elements are mandatory:

  • If 'video:action' is 'save' (resulting in a new asset with media file and metadata), then the following elements are mandatory:

o email
o video:referenceId
o video:type
o video:metadataFile
o video:format
o video:format:action (=save)
o video:format:mediaFile

  • If 'video:action' is 'delete' (resulting in the complete removal of the media and metadata files), then the next two elements are mandatory:

o email
o video:referenceId

  • If 'video:action' is 'update', with the intention to update the metadata file (resulting in the old metadata overwritten by the new, without changing the id), then the next elements are necessary:

o email
o video:referenceId
o video:metadataFile

  • If 'video:action' is 'update', with the intention to delete, update or add a media file, then there are three options:
    1. 'format:action' is 'delete' (resulting in the removal of the media file and its filename),
    2. 'format:action' is 'update' (resulting in the replacement of the existing media file by a new one, without changing de id),
    3. 'format:action' is 'save' (resulting in the addition of a new media file to the asset). o 'video:format:mediaFile' is the mandatory element in all three cases
  • The other metadata will only be handled under the following conditions:

o 'collections', 'categories', 'accessRules' and 'recentList' will only be handled if 'video:action' is 'save' or 'update'
o 'transcodings' will only be executed if 'video:format:action' is 'save' or 'update'