...
| 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 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? |
| 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 |
Review definition
Metadata that should exist in the file.
...
https://openreviewio-standard-definition.readthedocs.io/fr/latest/README.html
Notes
Notes are often going to be directly ingested into databases, but there will be cases where you want to send them from vendor to vendor. For this we may want to define a neutral excel format that is easy to read for non databases.
| 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. |
| 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 |
| 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.
Annotations
Annotations would need to be in a more computer readable format such as XML or JSON.
<review reviewid="<REVIEWID>">
<media sourceid="<SOURCEID>">
<annotation frame="<FRAMENUMBER>">
<line thickness="<SIZE>" style="<LINESTYLE>" color="<COLOR>">
<coord x="<X>" y="<Y>">
<coord x="<X>" y="<Y>">
<coord x="<X>" y="<Y>">
</line>
<brush style="" color="<COLOR>">
<coord x="<X>" y="<Y>" thickness="<SIZE>" opacity="<OPACITY>"/>
<coord x="<X>" y="<Y>" thickness="<SIZE>" opacity="<OPACITY>"/>
<coord x="<X>" y="<Y>" thickness="<SIZE>" opacity="<OPACITY>"/>
</brush>
<text x="<X>" y="<Y>" size="<SIZE>" label="<TEXT TO DISPLAY>" />
<colorcorrect x="<X>" y="<Y>" size="<SIZE>" area="<AREATYPE>" asccc="<ASC COLOR CORRECT>" />
</media>
</review>
Encoding standards
FFMPEG
Can we define ffmpeg standards for playback, including color space conversion. The default color space for ffmpeg is bt601, which is not typically what we are all using any more, but there are a number of conversion options that we should be considering. Its fairly typical to see the
...