Ubuntu Wiki

• Launchpad Entry: multimedia-ubuntuone-n-distributed-media-library

• Created:

• Contributors:

• Packages affected:

Summary

The Distributed Media Library is designed to bring Media Asset Management (MAM) to the freedesktop. It's designed to be suitable for both content creation (e.g. photo editors) and consumption (e.g. video players), and for both casual and professional apps. Key features are:

• Deduplication - media files are ID'd by their content-hash
• Synchronization and backup (e.g., you import some photos on a netbook, then they are automatically merged onto your desktop or cloud storage)
• Reclamation - tracks where media files are stored, so knows when a file can be safely deleted to free space
• Gracefully use a large library from a device with limited storage (e.g., netbook, tablet, phone)

Meta-data for the media files is stored in CouchDB, which means it will be easy to integrate with UbuntuOne. Each media file has a corresponding document in CouchDB, and the media file content-hash is used for the document ID:

• {"_id": "UB2VSXLKXSXBP44VQ5MHBPRBLVH7QWEW"}

The media files are stored on the file system in a special layout according the the content-hash:

• ~/.dmedia/UB/2VSXLKXSXBP44VQ5MHBPRBLVH7QWEW.png

Media files are moved between computers over HTTP. The meta-data for the entire library is stored on each device (meta-data is small), but a given device might have only a small subset of the media files (media files are big).

dmedia is being built for Novacut, but the goal is to make it useful across all freedesktop media apps. It would be nice to port a media app or two to dmedia during the Natty (11.04) cycle. PiTiVi seems like a great target as it doesn't yet have library functionality. Time permitting, Shotwell would probably be a good 2nd target.

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.

Rationale

User stories

• Tara is a professional photographer. She travels to shoot a wedding, and dumps her photos onto her laptop. When she returns home, she wants the new photos to be merged into her library, copied onto her workstation.
• Nathan is an aspiring filmmaker. He has several terabytes of video stored on a home server. He likes to browse through his library, tag and rate videos, as he sits on the couch with a tablet.

Assumptions

• Media files are read-only, editing is non-destructive
• Meta-data for the entire library can fit onto all devices used (partial meta-data support could be added in future)

Design

As the design stabilizes, we will create a freedesktop.org desktopcouch format spec (e.g., the Evolution contact spec). Here is the current rough format spec:

{
  "_id": string - media file content hash,
  "_rev": string - revision of document,
  "mime": string - mime type,
  "ext": string - lowercase file extension without leading period,
  "name": string - basename of originally imported file,
  "bytes": int - media file size in bytes,
  "mtime": float - timestamp as seconds since epoch (UTC),
}

For example:

{
  "_id": "XA5LIO6DK4U7FT3WNUFJFHI3X6MC4QGO",
  "_rev": "1-3306041dba9b52931a99f95063df8d70",
  "mime": "video/quicktime",
  "ext": "mov",
  "name": "MVI_5724.MOV",
  "bytes": 267163329,
  "mtime": 1287499122.94,
}

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec