...
| First Frame, Last Frame | int | Encoding to movie files typically looses the start frame, making it a pain to identify which frame you are looking at. We could look at doing this with timecode, but sometimes you want both timecode and a frame number. |
| Source filename | string | Something to track where the encoded media came from. |
| Source ID | string | Unique ID from vendor creating content. |
| Source frame rate | float | If you are reviewing a proxy, but still want to remap back to the source frame, knowing the source frame rate is required (DO WE NEED THIS AND LAST FRAME?) – useful for high-frame rate media, e.g. 120 fps - (MIGHT MAKE SENSE AS A STRING TO HANDLE 59.94 better?) |
| image active area | xMin, yMin, xMax, yMax | The bounding box of the picture location within the image. This is used in cases where the image is a re-processed version of the source frame, e..g. where a 2.35 aspect ratio picture has been padded to HD (perhaps timecode is burnt in, etc), this would allow any annotations to be always defined relative to the source frames, so would be able to be correctly overlayed on top. |
| Watermarking? | String | Document what sort of watermarking has been applied? - invisible, burnin? |
| Slate Length | Int | Duration of slate length (0 if no slate). |
| Display Type | Enum | Stereo left/right Stereo top/bottom Long/Lat VR mono Long/Lat VR Stereo top/bottom NOTE: This should be based on existing standards, e.g. https://github.com/google/spatial-media/tree/master/spatialmedia |
| Color Space | string | Many file-formats do already have options for color spaces, but certainly for internal reviews facilities may decide to encode to a non-standard color space. For media that is crossing facilities we should stick to known embedded colorspaces, and allow existing tools to remap where necessary. |
Review definition
Metadata that should exist in the file.
| Source ID | string | A unique ID for the company generating the media that can be used to get back to the original media. The main use of this is if the filename changes as it goes through different company pipelines. This may only be for reviewed media, rather than all media, and ideally its something reasonably compact and human readible, for example <SHOWCODE>-<REVIEWID> – spy-1234 – where reviewid is an incrementing ID per show. For this document we dont care about its structure, only that it exists. |
| Source Entity | string | Identifies the shot, asset or entity. Potentially useful as a burn-in. |
| Source sub entity | string | This would be the way to identify the media within the source entity without versions. e.g. lets say I have a filepath /shows/spy01/bat001/pix/rnd/precomp_v001/precomp_v001.0001.exr spy01 = SHOW bat001 = SHOT = Source Entity precomp = Source subentity This would be used by an asset management system to group versions, without having to guess what the versioning system is. |
| source sub entity version | float | Version ID for sub-entity. |
| Task | string | Taskname if known at creation - |
| colorspace | string | Many file-formats do already have options for color spaces, but certainly for internal reviews facilities may decide to encode to a non-standard color space. For media that is crossing facilities we should stick to known embedded colorspaces, and allow existing tools to remap where necessary. |
| date authored | string | The latest date of the original authored content. This would be carried through any transcoding, so we dont end up with the transcoded timestamps. |
Media Review Info
For doing external reviews (vendor passing media to production company) you may have additional metadata that needs to be passed with the media for review, this would typically be in an excel file (See VES Delivery Specification) with the following columns:
...
| Date Reviewed | String | |
| Reviewer Names | String | Who was doing the reviewing. |
| Review Location | String | Where it was. |
| ReviewID | String | A unique ID that can be used to map annotations to a review. Ideally this is something human-readable, e.g. YYYYMMDDHHMM-<Location> but from the file format point of view, its simply a string. |
| Source ID | String | Reference back to the media source. |
| Source Entity | String | i.e. the shot |
| Sub-source entity | String | i.e. the sub-source |
| Status | String | Approved/Not Approved/CBB |
| Notes | String |
Logically, the first three columns are really the header and in most cases are simply repeated, but it does simplify everything into a single table.
...