- From: Sean Hayes <Sean.Hayes@microsoft.com>
- Date: Sun, 13 Feb 2011 18:32:58 +0000
- To: David Singer <singer@apple.com>
- CC: HTML Accessibility Task Force <public-html-a11y@w3.org>
>> The video tag can point at anything, including RTSP controlled streams, and particularly it can point at chunked-over-HTTP manifest files Yes, I was more talking about the state of implementation rather than what the spec allows. There's no reason why fetching a time based media fragment from a chunked manifest couldn't return TTML files for the given time segments either. >> Whole documents do sound 'heavy' though. In what sense heavy? There is some overhead - typically I've observed around 10-12% of syntax to data in a typical TTML file; although with zip compression this disappears quite readily. But whole text files actually turn out to be significantly cheaper in terms of all-up data than subpicture type captions or bytes on every frame which are the two most prevalent models to date. >>but it only seems to allow covering language features, not characteristics of the stream (like, >>that it's in time order) or other functional aspects (like, CSS styling support), right? The TTML profiling feature is to allow documents to declare what features they rely on in order to be processed correctly. There is a base set of features that discuss styling at a fine grain and other functional features. There is no feature that describes relying on non-monotonic temporal ordering today; but there is an extension mechanism so that such a feature could be defined. However as I said, I don't think this is actually a big problem in practice. Sean.
Received on Sunday, 13 February 2011 18:33:37 UTC