You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey, is there existing practice for how streams holding video frame numbers may be annotated in terms of stream type and metadata? (I know some folks have been writing such integrations quite a while ago, e.g. @mgrivich). Also cc @cboulay (I saw that blackrock integration).
Off the top of my head, I think if nothing else the relative path to the actual video file should be written into the stream metadata (if the video is in a known relative location to the XDF), or otherwise at least the filename without any path information. I'd keep absolute paths out of the spec for obvious reasons.
In terms of stream type, one may be tempted to use the VideoCompressed type and allow in lieu of the <encoding> tag a different tag that indicates that the video is external to the XDF (e.g., <external>). Or we might invent a new tag like VideoExternal, which may avoid a failure mode in XDF/LSL pplications that expect VideoCompressed to contain the actual compressed video but then just find a frame stamp in it (after all, that sort of disambiguation is what stream types are therefore).
The text was updated successfully, but these errors were encountered:
Hey, is there existing practice for how streams holding video frame numbers may be annotated in terms of stream type and metadata? (I know some folks have been writing such integrations quite a while ago, e.g. @mgrivich). Also cc @cboulay (I saw that blackrock integration).
Off the top of my head, I think if nothing else the relative path to the actual video file should be written into the stream metadata (if the video is in a known relative location to the XDF), or otherwise at least the filename without any path information. I'd keep absolute paths out of the spec for obvious reasons.
In terms of stream type, one may be tempted to use the
VideoCompressed
type and allow in lieu of the<encoding>
tag a different tag that indicates that the video is external to the XDF (e.g.,<external>
). Or we might invent a new tag likeVideoExternal
, which may avoid a failure mode in XDF/LSL pplications that expectVideoCompressed
to contain the actual compressed video but then just find a frame stamp in it (after all, that sort of disambiguation is what stream types are therefore).The text was updated successfully, but these errors were encountered: