Introduction
3 minute read
Core principals
The core technology works like this:
- Sender
- Categorize metadata as { (
binary
ortext
) and (clocked
orunclocked
) } - Put metadata in an envelope according to category
- Stamp envelope with a MetaRex ID (
mrxId
) & timing information - Publish the
mrxId
in a public register so that anyone can figure out what the metadata is - Map the envelope(s) into a network transport for real time distribution
- Categorize metadata as { (
- Receiver
- Unmap network transport into a sequence of MetaRex envelopes
- Store / preserve / mux / process the envelopes as a file or stream
- Get
mrxId
registration info from the register - Process metadata / download a plugin / display a message based on the registration information provided by the owner of the registration record.
The MetaRex envelope - MXF
Why MXF
Looking at the tools available for packetizing a collection of abstract metadata elements, there are a few requirements that were needed:
- identification hierarchy aware of classes of data and instances of data
- clock metadata with precise clocks
- lock metadata timing to existing media clocks e.g. video / audio
- synchronize metadata with other streams e.g. video / audio / rtp / gps
- envelope text based metadata
- envelope unsynced timed data e.g. subtitles / elapsed time / script progress
- carry any metadata type without transcoding
- can securely encrypt content with an established Key Management Regime
- extend the system as it matures
Many candidates were considered including tar
, zip
, quicktime
, matroska
yet all of them lacked one or more of the key infrastructure elements to satisfy
the requirements.
** MXF **is 20 years old, widely deployed, has a sophisticated timing model, encapsulation model, an ID infrastructure that gives every MXF file in existence a unique number, an extensible data model, a field-tested encryption model, and has extension mechanisms including the ability to define in-file dictionaries for sophisticated parsing. There are also many different implementations including one in ffmpeg .
Basically, MXF already has the tools needed and the other options require significant work to create a general purpose global solution.
The MetaRex MXF profile
Some features of the MXF profile are extensions of the MXF-live profile that was demonstrated in 2019 at the ARRI Broadcast Day .
The MXF profile document is a work in progress - if you want to contribute to it or have issues with the design approach then please contact us or join the project to help us complete the work an give away the software.
Some desires of the final MetaRex MXF profile:
- it must be possible to serialize & stream an
mrx.mxf
over a network - it must be possible to concatenate a stream of
mrx.mfx
envelopes to an atomic OP1a MXF file - every partition of an
mrx.mxf
file must only contain one thing (Header, Index, Body, GSP, Footer etc.) - an
mrx.mxf
file must contain a minimum amount of descriptive metadata (DM-MRX) to enable rich identification via the MetaRex register. - an
mrx.mxf
file must contain a minimum amount of descriptive metadata (DM-MRX) to enable an appropriate time stamp for the metadata contained e.g. NTP derived time of day in ISO 8601 Timezone format. - an
mrx.mxf
file might contain richer MXF-native metadata. - an
mrx.mxf
file might contain richer timing metadata. - an
mrx.mxf
file might contain richer meta-metadata using KXS ( SMPTE ST 377-2 ).