Re: [whatwg] Captions, Subtitles and the Video Element
On Thu, 16 Jul 2009, Jeff Walden wrote: (For the few authors who really want to go crazy, they can already overlap HTML onto theirvideo and do whatever crazy stuff they want to do.) By way of a use case for at least color and positioning, there's a certain part of the third (?) Austin Powers movie wherein the color and position of foreign-language subtitles plays an important part in the artistic merits (lack thereof, arguably) of the scene. How would you suggest a movie-viewing site use video to display these? It seems unreasonable to say that the site must include special-case handling for this particular movie clip's subtitles; it's more likely they would be mangled in some manner and the semantic content (lack thereof) would be lost. By the way, I have no idea how foreign-language translations of the movie handle this scene. It's possible they simply subtitle the subtitles and avoid the more complicated problems this scene arguably presents. I think this particular case can be a victim of the 80% rule. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Captions, Subtitles and the Video Element
On 17.7.09 02:15, Ian Hickson wrote: I think this particular case can be a victim of the 80% rule. Fair enough, probably. Jeff
Re: [whatwg] Captions, Subtitles and the Video Element
On Fri, Jul 17, 2009 at 4:15 AM, Ian Hicksoni...@hixie.ch wrote: On Thu, 16 Jul 2009, Jeff Walden wrote: (For the few authors who really want to go crazy, they can already overlap HTML onto theirvideo and do whatever crazy stuff they want to do.) By way of a use case for at least color and positioning, there's a certain part of the third (?) Austin Powers movie wherein the color and position of foreign-language subtitles plays an important part in the artistic merits (lack thereof, arguably) of the scene. How would you suggest a movie-viewing site use video to display these? It seems unreasonable to say that the site must include special-case handling for this particular movie clip's subtitles; it's more likely they would be mangled in some manner and the semantic content (lack thereof) would be lost. By the way, I have no idea how foreign-language translations of the movie handle this scene. It's possible they simply subtitle the subtitles and avoid the more complicated problems this scene arguably presents. I think this particular case can be a victim of the 80% rule. I don't remember the exact scene you're referring to, but it's also possible that those subtitles are then an integral part of the content, and should properly be baked into the movie. ~TJ
Re: [whatwg] Captions, Subtitles and the Video Element
On 17/7/09 15:04, Tab Atkins Jr. wrote: On Fri, Jul 17, 2009 at 4:15 AM, Ian Hicksoni...@hixie.ch wrote: On Thu, 16 Jul 2009, Jeff Walden wrote: (For the few authors who really want to go crazy, they can already overlap HTML onto theirvideo and do whatever crazy stuff they want to do.) By way of a use case for at least color and positioning, there's a certain part of the third (?) Austin Powers movie wherein the color and position of foreign-language subtitles plays an important part in the artistic merits (lack thereof, arguably) of the scene. How would you suggest a movie-viewing site usevideo to display these? It seems unreasonable to say that the site must include special-case handling for this particular movie clip's subtitles; it's more likely they would be mangled in some manner and the semantic content (lack thereof) would be lost. By the way, I have no idea how foreign-language translations of the movie handle this scene. It's possible they simply subtitle the subtitles and avoid the more complicated problems this scene arguably presents. I think this particular case can be a victim of the 80% rule. I don't remember the exact scene you're referring to, but it's also possible that those subtitles are then an integral part of the content, and should properly be baked into the movie. Yep, slippery slope. If we're not careful we'll end up requiring a 3d file browsing facility, so that Jurassic Park can be properly represented - http://en.wikipedia.org/wiki/Fsn cheers, Dan
Re: [whatwg] Captions, Subtitles and the Video Element
On 15.7.09 17:56, Ian Hickson wrote: On Thu, 19 Feb 2009, Ian Fette wrote: However, there's a lot of uses for subtitles / captions that cannot be met with subrip. No styling (beyond the bare basics), no karaoke commands, no alpha, no nice handling for collisions, margins, shadow colors, specifying encoding, etc. I disagree that we should have author-controlled styling here. While I could maybe be convinced to have something basic like colour and maybe positioning, I think it is important that we let the subtitles be under the control of the user and the user agent, as they are, for instance, on TVs. Providing a way for authors to select different voices would make sense, but if we allow arbitrary styling we are going to have all kinds of problems, like lacking the ability to take subtitles and convert them to braille without losing context, or losing the ability to trivially convert subtitles for use in other contexts like TV subtitles. (For the few authors who really want to go crazy, they can already overlap HTML onto theirvideo and do whatever crazy stuff they want to do.) By way of a use case for at least color and positioning, there's a certain part of the third (?) Austin Powers movie wherein the color and position of foreign-language subtitles plays an important part in the artistic merits (lack thereof, arguably) of the scene. How would you suggest a movie-viewing site use video to display these? It seems unreasonable to say that the site must include special-case handling for this particular movie clip's subtitles; it's more likely they would be mangled in some manner and the semantic content (lack thereof) would be lost. By the way, I have no idea how foreign-language translations of the movie handle this scene. It's possible they simply subtitle the subtitles and avoid the more complicated problems this scene arguably presents. Jeff
Re: [whatwg] Captions, Subtitles and the Video Element
On Thu, 19 Feb 2009, Greg Millam wrote: Here is my proposal: [...] I think this proposal is a good direction to go in. However, I think it is still too early to put this in HTML5, and based on the quality of implementations so far, it will probably still be too early by the time HTML5 goes to last call in October. However, I think something similar to what you propose (which is similar, though more complex, to what Silvia proposed also) is what we should aim for once we are ready to add more features. On Thu, 19 Feb 2009, Ian Fette wrote: However, there's a lot of uses for subtitles / captions that cannot be met with subrip. No styling (beyond the bare basics), no karaoke commands, no alpha, no nice handling for collisions, margins, shadow colors, specifying encoding, etc. I disagree that we should have author-controlled styling here. While I could maybe be convinced to have something basic like colour and maybe positioning, I think it is important that we let the subtitles be under the control of the user and the user agent, as they are, for instance, on TVs. Providing a way for authors to select different voices would make sense, but if we allow arbitrary styling we are going to have all kinds of problems, like lacking the ability to take subtitles and convert them to braille without losing context, or losing the ability to trivially convert subtitles for use in other contexts like TV subtitles. (For the few authors who really want to go crazy, they can already overlap HTML onto their video and do whatever crazy stuff they want to do.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Captions, Subtitles and the Video Element
Greg Millam wrote: * All timed text tracks encoded in the video file are added to the list, as an implicit caption element. I'm not entirely sure what you mean, but I don't think implying a new element in the HTML based on text tracks within the media file is a good idea, and nor is it necessary. Instead, the UA just needs to obtain a list of available text tracks by combining those embedded within the media file with those linked to from the HTML, and make them all available to the user. * Caption tags, when displayed, count as span class=caption.../span unless they have style associated with them (uncommon). So they can be tweaked via CSS. Whether by the author or overridden by useragent. I do not understand what you mean here. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Captions, Subtitles and the Video Element
On 20.2.09 05:54, Lachlan Hunt wrote: Greg Millam wrote: * All timed text tracks encoded in the video file are added to the list, as an implicit caption element. I'm not entirely sure what you mean, but I don't think implying a new element in the HTML based on text tracks within the media file is a good idea, and nor is it necessary. Instead, the UA just needs to obtain a list of available text tracks by combining those embedded within the media file with those linked to from the HTML, and make them all available to the user. I think I agree with this; that caption or whatever would magically appear in the DOM as media data is downloaded (and in an unpredictable manner, from the point of view of the page author) seems baroque and unexpected. Jeff
Re: [whatwg] Captions, Subtitles and the Video Element
Instead of * getCaptionList(): returns an array of caption elements. Have * getCaptions(): returns an array of caption elements.
Re: [whatwg] Captions, Subtitles and the Video Element
Greg,
I think that it's important that there be something that everyone can depend
on being present across all UAs, so I commend your dedication here. I think
adding subrip as a baseline is a great idea so that everyone knows that
there's something that works everywhere, and subrip is dead simple.
However, there's a lot of uses for subtitles / captions that cannot be met
with subrip. No styling (beyond the bare basics), no karaoke commands, no
alpha, no nice handling for collisions, margins, shadow colors, specifying
encoding, etc. Without meeting these needs there's a number of people who
will just ignore video as they don't have something that will meet their
needs in all UAs.
As long as we're specifying some base set of standards that need to be
supported, you might as well pick one of the more full featured formats as
well. Personally I would suggest SSAv4+ (Advanced SubStation Alpha). I don't
want to get into religious wars over which is best, but the reality is that
it's in wide use and there's a number of tools for working with it.
You only get one chance to set a baseline standard, might as well make sure
that it covers all the use cases.
On Thu, Feb 19, 2009 at 2:37 PM, Greg Millam mil...@google.com wrote:
Hi guys -
I'm one of the main engineers responsible for captioning support on
YouTube, and I've joined the Chrome team at Google to attempt to help
drive video captions and subtitling forward: Both to implement support
in Chrome for it, and to push for HTML5 support for captions.
In my following statements, I am working off of a search through the
mailing list and reading of the HTML 5 spec. Particularly where the
Video tag is concerned. If there are any factual errors, or I'm way
off, just point my way. All this is as far as I can discover.
The current state of accessibility and captions in HTML5 has been
relegated to http://wiki.whatwg.org/wiki/Video_accessibility - a wiki
page with use cases, requirements, existing solutions, and an empty
Proposed Solutions category. I aim to fix that. My main goal here is
to prevent captioning from missing out on HTML5 and being dropped
because we never got around to it. (a la HDMI)
Here is my proposal:
Use cases:
* Accessibility.
* Ability to audiences in other languages.
Goals:
* Allow movie formats to include captioning support.
* Make it simple for an author to create and publish transcripts,
without requiring them to embed it into the movie.
* Make it simple for caption or subtitle tracks to be accessible.
* Allow full javascript control: List, add, delete, and create caption
tracks.
* Provide a required format to act as a baseline across all browsers.
The current state of the video element includes support for defining
a source video file, local or remote. There is no method to define a
caption source or track.
Proposed Solution:
HTML5 / Page Author:
* Each video will have a list of zero or more Timed Text tracks.
* A track has three variables for selection: Type, Language, Name.
These can be null, except for name.
* Type is a string, and may be (but is not limited to): Caption
Transcript Translation Subtitles, etc. Others can be defined by
the user (e.g: Commentary User Comments).
* Language is a language code (en, es, pt_BR, etc)
* Name is a freeform text identifier. By default, default or
caption. If a video file has multiple tracks, they are added as
caption1 caption2, etc.
* video . . . /video is not necessarily a standalone tag. If the
author desires, they can add more elements to define tracks. Whether
this should be caption type=format src=... media=caption or
source type=timedtext/format src=... can vary. (I prefer
caption as it's more explicit).
* caption src=foo.srt type=caption language=en name=default
/ adds a new caption. caption is standalone.
* All timed text tracks encoded in the video file are added to the
list, as an implicit caption element.
* Caption tags, when displayed, count as span
class=caption.../span unless they have style associated with them
(uncommon). So they can be tweaked via CSS. Whether by the author or
overridden by useragent.
User Agent:
* Implements support for caption tag.
interface MediaCaptionElement : HTMLElement {
attribute DOMString src;
attribute DOMString format; // default: auto.
attribute DOMString type;
attribute DOMString language;
attribute DOMString name;
attribute DOMBoolean enabled;
};
* Media elements now have a list of Captions associated with it.
* Support for (at minimum) Subrip format. Subrip I choose here for
the same reason we picked it for YouTube: It's readable,
understandable, and simple. You can create one with your favorite
editor. Subrip has no style associated with individual captions, so
can be subject to CSS caption rules for SPAN.caption
* Support for other formats (608, 708, .ass, dfxp, etc) up to
Re: [whatwg] Captions, Subtitles and the Video Element
Greg - Interesting ideas! A few questions that occur to me on first read: On Feb 19, 2009, at 2:37 PM, Greg Millam wrote: HTML5 / Page Author: * Each video will have a list of zero or more Timed Text tracks. * A track has three variables for selection: Type, Language, Name. These can be null, except for name. I am confused by your terminology. Does Timed Text track refer to the caption elements, or the caption tracks in the media file, or both? The term Time Text track has a very specific meaning in a media file, so unless that is what you mean I think another term would be preferable. * All timed text tracks encoded in the video file are added to the list, as an implicit caption element. When should the UA create the implicit caption element(s) from the tracks in the media file? What should it do about caption samples that are spread throughout the media file? * Caption tags, when displayed, count as span class=caption.../span unless they have style associated with them (uncommon). So they can be tweaked via CSS. Whether by the author or overridden by useragent. So by default, all of the captions (along with number and time stamps) for the entire file are displayed at the same time? eric
Re: [whatwg] Captions, Subtitles and the Video Element
On Feb 20, 2009, at 00:37, Greg Millam wrote: The current state of accessibility and captions in HTML5 has been relegated to http://wiki.whatwg.org/wiki/Video_accessibility - a wiki page with use cases, requirements, existing solutions, and an empty Proposed Solutions category. Since then, the active work has moved to the Mozilla wiki and to Xiph: https://wiki.mozilla.org/Special:Search?search=captions http://lists.xiph.org/pipermail/accessibility/ http://wiki.xiph.org/index.php/Timed_Divs_HTML Silvia Pfeiffer has been working on this as a Mozilla Foundation grantee. * video . . . /video is not necessarily a standalone tag. If the author desires, they can add more elements to define tracks. Whether this should be caption type=format src=... media=caption or source type=timedtext/format src=... can vary. (I prefer caption as it's more explicit). FWIW, you can't use the element name caption for legacy reasons. You can't use the element name text, since that would introduce new name collisions with SVG 1.1. * Support for (at minimum) Subrip format. Subrip I choose here for the same reason we picked it for YouTube: It's readable, understandable, and simple. You can create one with your favorite editor. Subrip has no style associated with individual captions, so can be subject to CSS caption rules for SPAN.caption I agree it makes sense to start with something simple. The markupless flavor of SRT would be such a format. However, supporting the formatting tags in later flavors of SRT is a can of worms: You'd quickly end up introducing a third HTML/XML-like parser into the browser. Further, the formatted flavors of SRT have become victims of the same problem that the RSS title became a victim of. Let's not go there. For formatted captions, I think it makes sense to overlay a browsing context onto the video and make HTML/CSS-based captions render into that browsing context on the main thread (tolerating some timing jitter relative to the video track). http://wiki.xiph.org/index.php/Timed_Divs_HTML is a proposal to this direction, but it lacks a concrete processing model proposal at present. * Support for other formats (608, 708, .ass, dfxp, etc) up to the user agent. (But preferred!) DFXP reinvents a lot of stuff that browsers already implement in their CSS formatter. From a browser code reuse point of view, it makes more sense to use HTML+CSS. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
