Page Comparison

...

First Frame, Last Frame	int	Encoding to movie files typically loses 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. - This could be using: https://proto.school/content-addressing/04
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.

Screen coordinate system could be based on: https://github.com/desruie/OpenTimelineIO/blob/autodesk_desruie_spatial_doc/docs/tutorials/spatial-coordinates.md

Review definition

Metadata that should exist in the file.

...

https://wiki.multimedia.cx/index.php/FFmpeg_Metadata

https://python-xmp-toolkit.readthedocs.io/en/latest/

XMP data can be read by ffprobe, e.g.: ffprobe -v quiet -print_format json -show_format -export_xmp 1 -show_streams "[0000-0119].mov"

Also, exiftool appears to have support for reading and writing xmp data: https://exiftool.org/forum/index.php?topic=8745.0 certainly , see: https://exiftool.org/TagNames/QuickTime.html

Annotations and Notes

The other area that common specifications could be defined is how annotations and notes could be sent back to the vendor, in a format that is ready for ingest into the tracking system.

...

Annotations would need to be in a more computer readable format such as XML or JSON. e.g.:

<review reviewid="<REVIEWID>{REVIEWID}" datereviewed="{DATEREVIEW}" reviewby="{REVIEWBY}" reviewlocation="{REVIEWLOCATION}">
    <media sourceid="<SOURCEID>{SOURCEID}">
       <notes>
            {NOTES}
       </notes>
       <annotation frame="<FRAMENUMBER>{FRAMENUMBER}">
          <line thickness="<SIZE>{SIZE}" style="<LINESTYLE>{LINESTYLE}" color="<COLOR>{COLOR}">
               <coord x="<X>{X}" y="<Y>{Y}"/>
               <coord x="<X>{X}" y="<Y>{Y}"/>
               <coord x="<X>{X}" y="<Y>{Y}"/>
          </line>
       <brush style="" color="<COLOR>">
          <coord x="<X>{X}" y="<Y>{Y}" thickness="<SIZE>{SIZE}" opacity="<OPACITY>{OPACITY}"/>
          <coord x="<X>{X}" y="<Y>{Y}" thickness="<SIZE>{SIZE}" opacity="<OPACITY>{OPACITY}"/>
          <coord x="<X>{X}" y="<Y>{Y}" thickness="<SIZE>{SIZE}" opacity="<OPACITY>{OPACITY}"/>
        </brush>
        <text x="<X>{X}" y="<Y>{Y}" sizefontsize="<SIZE>{SIZE}" label="<TEXT{TEXT TO DISPLAY>DISPLAY}" />
        <colorcorrect x="<X>{X}" y="<Y>{Y}" size="<SIZE>{SIZE}" area="<AREATYPE>{AREATYPE}" asccc="<ASC{ASC COLOR CORRECT>CORRECT}" />
   </media>
</review>