Re: [sdw] WebVMT: Review media block concept against WebVTT (#1099)

Media Timed Events Task Force (MTE TF) is focussed on rendering activities, rather than search, to the extent that the [Geolocation Rapid Indexing]( use case I submitted was not included in the [MTE Editor's Draft]( As the main purpose of the WebVMT media block is to enable rapid indexing, I see no compelling requirement in WebVTT currently.

The [WebVMT media block]( is mandatory but may contain [no settings]( to ensure that it always remains visible, even in the few cases when it's not used, for exactly the reasons you mention.

My understanding is that WebVMT is an out-of-band solution in media terminology, as the VMT file is separate to the media file, so using the HTML `<track>` element to associate it with a `<video>` element is a consistent approach. For HTML purposes, the [WebVMT media block]( is a 'hint', as I mentioned in the TPAC [breakout session](, so I'd expect the HTML association to take precedence.

I can think of two web use cases where the [WebVMT media information]( is not provided by HTML:

   1. **Video archive:** A PHP script generates HTML pages on-the-fly from a collection of files in a video archive, which requires information to associate the correct VMT and media files.

   1. **Multiple file input:** Files loaded using `<input type="file" multiple>` are delivered in an arbitrary order. If more than two files are loaded, media and VMT files must be correctly paired.

I can understand the need for shared subtitle files where media files have common audio tracks, as the subtitle text is related to the audio. However, I don't see a comparable requirement for WebVMT as the VMT file relates to (and is typically created by) the video capture device, i.e. the camera, which is unique. Hence, I don't see a WebVMT use case for track reuse.

   1. **TV vs radio:** Creating separate media files for TV or radio is an editing activity, so it's not unreasonable to expect corresponding separate VMT files to be created at the same time by the editing suite for each media file produced.

   1. **Multiple camera angles:** Recording separate camera angles requires multiple cameras, each creating their own unique VMT file. Even though the moving object path may be common, the VMT files captured by each camera would be different by definition. For example:
        - Colocated cameras facing in different directions, e.g. forward- and rear-facing cameras on a vehicle.
        - Non-colocated cameras observing the same target, e.g. dashcam and roadside cameras.

If there is a need for a single VMT file to associate with multiple media files, a simple way to achieve this would be to allow multiple [WebVMT media block]( definitions within the same file and I'd be interested to know what the use case is.

The editing suite would be responsible for ensuring that the [WebVMT media block]( is correctly defined in the VMT file, though I agree that this could be a pitfall for manual editing.

GitHub Notification of comment by rjksmith
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 28 November 2018 12:58:41 UTC