MediaTypeRefactor/DesignDoc

Media Types Design

This document is based on requirements/wishes listed in http://wiki.mediagoblin.org/MediaTypeRefactor

• Note*: * Attachments have deliberately been excluded from this document to reduce complexity

Publishing clients

These are described optimal behaviours of different types of publishing clients.

CLI

Single-file

{{{ gmg submit FILE }}}

*n*-file

{{{ gmg submit FILE_1 FILE_2 [...] FILE_N }}}

*n*-file with media metadata

GStreamer `gst-launch` inspired exclamation-mark-separated "elements" of media entries:

{{{ gmg submit FILE_1 title=TITLE_1 description=DESCRIPTION_1 ! \

   FILE_2 title=TITLE_2 ! \
   FILE_3 title=TITLE_3 tags=TAGS_3[...]

}}}

WWW

*n*-file

• Note*: Requires browser drag and drop support.

S U B M I T   F I L E S                       

• Note*: * What if there's folders in there?

 * What about publishing-metadata?

Single-file

Could be used as fallback for browsers not supporting drag and drop.

S U B M I T   F I L E                         

API

TBD

Media types

Installation

{{{ pip install mediagoblin-video echo "mediagoblin.media_types.video" >> mediagoblin_local.ini gmg dbupdate }}}

• Note*: * We could build a wrapper around pip that performs the installation steps automatically.

 * What about dependencies such as GStreamer and related packages? We could include that in our wrapper, but it'd have to take into account all the different distributions' package managers out there.

Negotiation

Media type negotiation is done per-file by iterating through a registry of enabled media type plugins. Several negotiation mechanisms may exists, such as a cheap file-extension based one and a more expensive file content sniffing negotiation step.

Output files

Some media types such as ASCII art and images might have a very simple data structure:

{{{ This illustrates the output of the ``mediagoblin.media_types.image`` media type:

ORIGINAL IMAGE -> THUMBNAIL JPEG

                    MEDIUM SIZED JPEG

}}}

Media types such as `video` and `3D object` might have more complex output files:

{{{ ORIGINAL VIDEO -> THUMBNAIL JPEG

                      640px-wide WEBM # Displayed on media page
                            720p WEBM # Displayed in full-screen player
                           1080p WEBM # Displayed in full-screen player
                     640px-wide H.264 # Alternate container/stream formats
                           720p H.264
                          1080p H.264

}}}

we should therefore allow a lot of flexibility for the files

Media processing

Processing takes the original file and creates files of lesser size/quality that The pipeline is as follows:

 # The application receives a bytestream, optional byte stream metadata (i.e. filename) and publishing-metadata. The bytestream and bytestream metadata is sourced from the *original file*.
   * Possibly we could have "adapters" of some sort that provides this data consistently across publishing clients.

• Note*: Some users have expressed a wish for mediagoblin to simply read a folder with files and create a "web album" from them.

 * The media type negotiation mechanism decides one or more suitable media type plugins to handle the conversion of the *original file*, pushes task data to the task broker and creates a *MediaEntry* in the database and populates it with at least the media type.
 * The task handler now checks the task broker for a new task when received the task handler looks up the processing method for the selected media type and runs it.
 * The media processor converts the *original file* into smaller, displayable media. These media files are then placed in the *public storage*.

• Note*: * Are there cases where we should accept more than one input file?