Wide Review Comment 2017: Timing

[nigelmegitt]

Copy/paste from https://lists.w3.org/Archives/Public/public-tt/2017Sep/0080.html - raising as an issue for tracking/disposition purposes.

WebVTT timing does not specify the time base that applies, except by reference to HTML5.1 media timelines. In general it is assumed to be media time, i.e. The first frame of the video is time zero. That makes sense in relation to a distributed piece of media such as would be present in an HTML video track. However there are broadcast usages of subtitle files that need to relate times to embedded timecode in video. It may be that such practices are phased out over time; until that occurs however, there is no defined data structure in WebVTT (even as metadata) that allows the processor to understand how to relate timestamps to the media with which the file is somehow associated, or indeed how the timestamps were generated.

For example, if a WebVTT file were authored against embedded timecode timestamps, but then that file were accidentally re-used against video media stripped of such timestamps, the content would display at the wrong time, but there would be no information available within the WebVTT file to identify that such a scenario had occurred.

[dwsinger]

VTT has a common timeline as the media it's associated with. Like MP4 files, it plays from the beginning. Aligning the captions, when they are in a separate file from the media, is the job of the layer that puts them together (DASH, HTML, etc.).

[nigelmegitt]

Right, but then there's an asset management problem. We have videos with timecode in them, typically beginning at 10:00:00 (DPP specification if you want to look it up), which are played out in the broadcast infrastructure, and are then also transcoded and published online without the timecode. At the moment there's no way to inspect the WebVTT file and work out if it is associated with the right video, i.e. if it uses 10:00:00 referred timestamps or 00:00:00 referred timestamps.

In other words, accepting that in principle a WebVTT transcode would be needed to fix the timestamps, we would want to be able to look at a file and decide if it has been done already, primarily in operational scenarios when a support team might want to trace an issue.

[dwsinger]

I would suggest that you use external or intrinsic data if you want to manage VTT further up your workflow; e.g. while it's inside the BBC you could have a comment convention for the timecode, asset-ID and other association information.

[nigelmegitt]

you could have a comment convention

Okay that might be possible, but not interoperable across organisations generally. It would be lower cost to industry and generally preferable to have some agreed conventions. Since you are raising the idea of using comments I guess those conventions could in principle be agreed in a different context or document.

[dwsinger]

I thought the question was about your internal workflow, and that's how I answered it, but yes, you can agree on any conventions you like between orgs as well (e.g. between BBC and your captioning house).

[dwsinger]

I think the comments identify a possible way ahead, and adding a feature like time-code support is a major step we should defer to v2. Proposing therefore -rejected labels for this issue for this version.

[silviapfeiffer]

I agree with David, I think this is a clear situation for using comments.

E.g. put this at the beginning of your WebVTT file:

NOTE VIDEO_REFERRED_TIMESTAMP=10:00:00

I'd like to close this issue as "works for me"

[dwsinger]

WFM

[silviapfeiffer]

Waiting for commenter feedback, but closing as resolved.

[nigelmegitt]

Thanks, the option to include some additional data is present but cannot be used interoperably due to lack of agreed syntax etc, so marking this as commenter-agreed-partial.