Video Overlay - Revision history

Annevk: /* References */

2011-01-26T12:13:05Z

References

← Older revision		Revision as of 12:13, 26 January 2011
Line 155:		Line 155:
	* [http://lists.w3.org/Archives/Public/public-html-a11y/2009Nov/0098.html initial <overlay> suggestion] from Philip Jägenstedt (Opera) with feedback from Eric Carlson (Apple)		* [http://lists.w3.org/Archives/Public/public-html-a11y/2009Nov/0098.html initial <overlay> suggestion] from Philip Jägenstedt (Opera) with feedback from Eric Carlson (Apple)

	[[Category:~~Feature Request\|empty Template~~]]		[[Category:Proposals]]

Philipj: move DOM API section

2009-11-30T09:44:49Z

move DOM API section

@@ Line 88: / Line 88: @@
 :''Should &lt;overlay> be a block or an inline element?''
-==== DOM API ====
+==== Limitations ====
 HTML5 used to have a cue ranges feature with this API:
@@ Line 113: / Line 128: @@
 :''TODO: Better interface/method/event names and code examples''
 === Baseline Formats ===

Philipj: /* Styling */

2009-11-30T09:42:12Z

Styling

← Older revision		Revision as of 09:42, 30 November 2009
Line 86:		Line 86:
	It needs to be defined exactly what <overlay> is to <video>. The simplest may be acting as if <video> were the containing block for <overlay> elements, so that e.g. applying <tt>position:absolute;bottom:0;left:0;right:0</tt> on <overlay> causes it to be position at the bottom of the parent <video>.		It needs to be defined exactly what <overlay> is to <video>. The simplest may be acting as if <video> were the containing block for <overlay> elements, so that e.g. applying <tt>position:absolute;bottom:0;left:0;right:0</tt> on <overlay> causes it to be position at the bottom of the parent <video>.

	:''Should <overlay> ~~could~~ be a block or an inline element?''		:''Should <overlay> be a block or an inline element?''

	==== DOM API ====		==== DOM API ====

Philipj: the diff of this proposal compared to

2009-11-30T09:27:53Z

the diff of this proposal compared to <itext>

← Older revision		Revision as of 09:27, 30 November 2009
Line 1:		Line 1:
	There are several types of content which should be displayed overlayed on <video> elements, including subtitles/captions from various sources, scripted controls and more advanced scripted content such as karaoke or timed annotations. <~~overlay~~> ~~suggested below tries to provide~~ a ~~simple markup to enable all such uses~~.		There are several types of content which should be displayed overlayed on <video> elements, including subtitles/captions from various sources, scripted controls and more advanced scripted content such as karaoke or timed annotations.

			On top of what proposals such as <itext> already support (with another syntax), this proposal is mostly concerned with styling, specifically consistent CSS styling of captions/subtitles and a hook into fullscreen rendering which is necessary for providing the same experience (in terms of controls, subtitles, etc) regardless of display mode.

	== Use Case Description ==		== Use Case Description ==

Philipj: /* References */

2009-11-29T11:02:38Z

References

← Older revision		Revision as of 11:02, 29 November 2009
Line 146:		Line 146:
	Silvia Pfeiffer's <itext> proposals:		Silvia Pfeiffer's <itext> proposals:
	* [https://wiki.mozilla.org/Accessibility/HTML5_captions HTML5 captions] ([https://wiki.mozilla.org/Accessibility/Experiment1_feedback feedback])		* [https://wiki.mozilla.org/Accessibility/HTML5_captions HTML5 captions] ([https://wiki.mozilla.org/Accessibility/Experiment1_feedback feedback])
	* [https://wiki.mozilla.org/Accessibility/HTML5_captions_v2 HTML5 captions v2]		* [https://wiki.mozilla.org/Accessibility/HTML5_captions_v2 HTML5 captions v2] ([https://wiki.mozilla.org/Accessibility/Experiment2_feedback feedback])
	Mailing lists:		Mailing lists:
	* [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014887.html re-thinking "cue ranges"] from David Singer (Apple)		* [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014887.html re-thinking "cue ranges"] from David Singer (Apple)

Philipj: /* SRT */

2009-11-28T18:36:44Z

SRT

← Older revision		Revision as of 18:36, 28 November 2009
Line 131:		Line 131:

	==== SRT ====		==== SRT ====
	SRT is probably the most widely supported and also one of the simplest subtitle formats. However, ~~there is no spec for the format, rather different~~ applications ~~all~~ parse it differently. In order to use it on the web we need an SRT parsing ~~specification~~. ~~That~~ would entail gather lots and lots of SRT files from the wild and trying to define the algorithm such that it is compatible with as many as possible. Many SRT files has some limited HTML markup like <b> and <i>. A decision would have to be made whether or not to include that in the parsing algorithm.		SRT is probably the most widely supported and also one of the simplest subtitle formats. However, all applications seems to parse it differently. In order to use it on the web we need an SRT parsing algorithm spec. Writing such a spec would entail gather lots and lots of SRT files from the wild and trying to define the algorithm such that it is compatible with as many as possible. Many SRT files has some limited HTML markup like <b> and <i>. A decision would have to be made whether or not to include that in the parsing algorithm.

	==== W3C Timed Text ====		==== W3C Timed Text ====

Philipj: captioning formats

2009-11-28T18:34:33Z

captioning formats

← Older revision		Revision as of 18:34, 28 November 2009
Line 126:		Line 126:
	* Simple, stylable subtitles/captions without using scripts.		* Simple, stylable subtitles/captions without using scripts.
	* Less work to position scripted controls on top of <video>		* Less work to position scripted controls on top of <video>

			=== Baseline Formats ===
			For <overlay src="captions"> or any other solution referencing external captions/subtitles to be interoperable, a baseline format is required.

			==== SRT ====
			SRT is probably the most widely supported and also one of the simplest subtitle formats. However, there is no spec for the format, rather different applications all parse it differently. In order to use it on the web we need an SRT parsing specification. That would entail gather lots and lots of SRT files from the wild and trying to define the algorithm such that it is compatible with as many as possible. Many SRT files has some limited HTML markup like <b> and <i>. A decision would have to be made whether or not to include that in the parsing algorithm.

			==== W3C Timed Text ====
			The [http://www.w3.org/AudioVideo/TT/ W3C Timed Text (TT) Working Group] is producing [http://www.w3.org/TR/ttaf1-dfxp/ Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)]. It is "a content type that represents timed text media for the purpose of interchange among authoring systems". The features are essentially the union of all features of all other timed text formats, which unsurprisingly makes it quite complex. While it can be used as an distribution format, using it as a baseline format requires that browser vendors show interest in implementing it.

	== References ==		== References ==

Philipj: /* Current Usage and Workarounds */

2009-11-28T17:13:39Z

Current Usage and Workarounds

← Older revision		Revision as of 17:13, 28 November 2009
Line 17:		Line 17:

	=== Current Usage and Workarounds ===		=== Current Usage and Workarounds ===
	Currently no browser supports rendering in-band subtitles~~, so there are no workarounds for styling~~ them. Fullscreen support is still immature, but there is no possible workaround for having scripted captions or controls to appear in fullscreen display.		Currently no browser supports rendering in-band subtitles and a workaround would involve extracting the captions on the server-side and sending them in another format. Fullscreen support is still immature, but there is no possible workaround for having scripted captions or controls appear in fullscreen display.

	==== Scripted Captions ====		==== Scripted Captions ====

Philipj: /* Implementation */

2009-11-28T15:15:33Z

Implementation

← Older revision		Revision as of 15:15, 28 November 2009
Line 118:		Line 118:

	==== Implementation ====		==== Implementation ====
	:'~~'Description of how and why browser vendors would take advantage~~ of ~~this feature~~.''		Browser vendors get the following benefits:
			* Since overlay content is explicitly marked up, it's easier to ensure that scripted overlays do not interfere with the native controls simply by placing native controls on top of the overlays.

	==== Adoption ====		==== Adoption ====

Philipj: /* Adoption */

2009-11-28T15:13:23Z

Adoption

← Older revision		Revision as of 15:13, 28 November 2009
Line 122:		Line 122:
	==== Adoption ====		==== Adoption ====
	Authors get the following benefits:		Authors get the following benefits:
			* With HD video becoming more and more common, most UAs will likely provide a fullscreen modes for <video>. This proposal gives authors a way to provide scripted enhancements even in fullscreen mode.
	* Simple, stylable subtitles/captions without using scripts.		* Simple, stylable subtitles/captions without using scripts.
	* ~~With HD video becoming more and more common, most UAs will likely provide a fullscreen modes for~~ <video>~~. This proposal gives authors a way to provide scripted enhancements even in fullscreen mode.~~		* Less work to position scripted controls on top of <video>

	== References ==		== References ==