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

> It's presence is mandatory for WebVMT to enable rapid indexing, so only the VMT file need be parsed during a search. Though not as essential to WebVTT, this could be a useful optional feature.

Why wouldn't the rapid indexing argument be as essential to WebVTT?

Re-reading the current draft, I note that the WebVMT media definition block is mandatory, but that it may be empty given that a [WebVMT media settings list]( "consists of **zero or more** of the following components". That is probably not what you want.

One reason I believe it is a good point to discuss with timed text guys is that this seems to go against the way tracks are being associated in the media world, be them in-band tracks or out-of-band tracks. For in-band tracks, tracks are associated within a media container. For out-of-band tracks, the `<video>` element acts as the container with `<track>` children linking text tracks to media tracks. In both cases, I believe this is done so that tracks may be reused in other contexts. For example, back to WebVMT, what about the following situations:
1. Someone records a trip to a foreign country to create a TV/Radio documentary (à la [J'irai dormir chez vous]( For TV, the documentary consists of a media file with a video and audio track, and of a WebVMT file. For radio, the documentary consists of a media file that only contains the audio track, and of the same WebVMT file. If the WebVMT file needs to link to a media file, which media file should it link to?
2. Same idea for situations where there are multiple cameras, creating multiple media files for the same media timeline. Which media file should a WebVMT file be associated with?

In other words, there are related media tracks (video, audio) that can produce different media files. For indexing and archival purpose, I'd want a way to associate a WebVMT file to these different media files, which is what the `<track>` element gives me in HTML.

Also, having the link at the WebVMT level seems error prone: it's easy to forget to update the link (e.g. if the name of the media file changes) and this would not have any noticeable effects for rendering (or would it?).

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

Received on Thursday, 22 November 2018 14:26:33 UTC