Difference between revisions of "Transcoder"

From Archivematica
Jump to navigation Jump to search
Line 31: Line 31:
 
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px">
 
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px">
 
This text is not collapsible; but the next is collapsible and hidden by default:
 
This text is not collapsible; but the next is collapsible and hidden by default:
<div class="mw-collapsible-content">I write what I need here{{exampleTemplate}}</div>
+
<div class="mw-collapsible-content"></div>
 
</div>
 
</div>
  

Revision as of 14:03, 21 August 2012

Transcode: convert (language or information) from one form of coded representation to another.[ source: Oxford English Dictionary ]

Overview

The transcoder is developed by artefactual, for the purpose of normalization and generating access copies in the archivematica system. In earlier versions it was called normalizer. It will try to identify the file type by the file extension, or other metadata, and look for matching configured actions for those identified. It will then perform those actions, and exit with a zero status if it believes those actions have been completed successfully.

Transcoder Database

In Archivematica release 0.7.1 alpha, the normalalization rules have been moved to a database, and can be seen under the preservation planning tab on the dashboard. In future releases, we plan to support modification of these rules through the dashboard interface.

Database Schema

Transcoder database schema.png

Configuration

Configuration files are located in the /etc/transcoder/ directory.

The transcoder database credentials and server can be set in the dbsettings.conf file.

Development

In the 0.9 release the transcoder was integrated with the MCP.

During transfer processing, the fileIDs are identified by microservices. They are stored against the file in the FilesIDentifiedIDs table.

For normalization processing, the MCP will process down a chain for each file. The job for normalization of a file will check for command relationships with the identified file id's and the proper command classification (normalize preservation, normalize access). For every unique command found in that relaitonship, the MCP will create a task to be executed by the client. If no commands are identified the MCP will create a task with the default command, from the DefaultCommandsForClassifcations table, if one is defined.


Integration with the MCP was done by relating commands to Microservice chain links. The Transcoder links (MicroserviceDChainLinks of this type) have a one to one relationship with the tasksConfigs, which have a one to one relationship with the CommandRelationships. The protocol between the client and server is based on the command Relationships's pk. The MCP assigns a task to the client to perform x commandRelationship on y file (identified by fileUUID). The client can pull the information required to execute the command from the database.

Why the change? To support all clients not having to support all normalization tools, the tasks needed to be assigned by tool availibility. Currently the archivematica-client package depends on all the tools required, but there are situations where this will be required. While these are not currently implemented an example would be normalizing on a windows machine, using microsoft office. The windows machine could theoretically run a client, but it wouldn't be able to support the standard archivematica tools, as they are linux based. To differentiate the two, use the supportedBy field in the Commands table.

Example

Some stuff

This text is not collapsible; but the next is collapsible and hidden by default:

Future Development

We are considering building a Format_policy_registry.