W3C home > Mailing lists > Public > public-sdwig@w3.org > January 2019

Re: [sdw] WebVMT: Investigate better out-of-band link handling (#1107)

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Thu, 10 Jan 2019 14:33:23 +0000
To: public-sdwig@w3.org
Message-ID: <issue_comment.created-453115881-1547130802-sysbot+gh@w3.org>
> This use case is equally applicable to WebVTT content.

Precisely. There is nothing specific to WebVMT there and so it seems useful to look at how things get done for other companion track files.

The usual media-centric response is to embed all tracks in the media container. WebVMT starts on the premise that the file will be maintained externally. However, I note that people might still choose to embed WebVMT content within the media container, as done for [WebVTT in Matroska](https://www.matroska.org/technical/specs/subtitles/webvtt.html).

For external subtitles, a naming convention seems to be the most common pattern: given a local media file, media players will look for subtitle files that have the same name (and e.g. that have an `srt` extension) in the same folder. That is not very satisfactory, but this seems to be how things are done.

I note that a media file can be associated with a number of external files, for instance external subtitles, a WebVMT file, a file that describes notable events, a video file with sign language, etc. The linking problem extends to all of these files. I'd say that there are four main ways to manage the links:
1. Through a file naming convention. I don't think that works over HTTP where one cannot list available resources on an HTTP server to know which ones to fetch.
2. By embedding the files into a common media container. That is the usual media-centric response. It requires more tooling and makes editing "by hand" impossible.
3. By including links to external files in the media container. I'm not sure whether container formats allow to include such metadata. That doesn't seem to be something that gets done in practice.
4. By recording the links at a different layer as typically done in HTML through the track element. I guess one could also envision HTTP Link headers (which the media player could parse when it fetches the initial media file). And obviously this could be done using RDF or a simple JSON or text-based data structure. That is how things are done on the Web. The obvious drawback is that one needs to manage yet another file.

Putting a link to the media file in each of the external track file seems wrong to me since it does not give you a way to assemble these files together unless you already know that all of these files exist. But then, if you know that all of the files exist as in the playlist use case, the common practice seems to be an implicit link through a naming convention.

All in all, I don't have a good solution to propose for managing these links, I just feel that this is better addressed at a different level and not within WebVMT, where it wouldn't provide a solution for all use cases. That's all your call though, feel free to proceed with the WebVMT media block as currently specified!

-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at https://github.com/w3c/sdw/issues/1107#issuecomment-453115881 using your GitHub account
Received on Thursday, 10 January 2019 14:33:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:52 UTC