This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Use case: Allow software developers based in the US who believe they will be covered by the CFR 79.103 rules to support captions while only implementing WebVTT, by allowing caption text to be displayed within one or separate caption windows in a mode where text scrolls up as new text appears. We should probably not _require_ this since studies show it's a bad way of doing captions, so whatever solution we have needs to support showing the same captions as either scrolling captions or regular captions.
It was the intention of the "Region" spec indeed to be backwards compatible such that UAs that don't want to implement support for "Region" will continue to render the cues as regular cues: http://www.w3.org/community/texttracks/wiki/MultiCueBox . The "scroll" setting was limited to the "Region".
So some of the problems I see with the region proposal above is that there doesn't seem to be a mechanism to style those regions, there doesn't seem to be a way to give their lifetime, and it duplicates a lot of the language from regular cues to define the regions. An alternative approach could be to have a way for a cue to say "add me to this earlier cue, pushing up the data". It could look a bit like this: WEBVTT fred 00:00:05.940 --> 00:00:10.610 When I get a sick bird, 00:00:07.040 --> 00:00:11.700 continue:fred that just stops everything Position information would go in the first cue, a cue with 'continue' would just push its line(s) onto the bottom of the that cue, scrolling them up accordingly.
(In reply to comment #2) > So some of the problems I see with the region proposal above is that there > doesn't seem to be a mechanism to style those regions What kind of styling are you referring to? The wiki page proposes to use a CSS pseudo-selector: ::cue-region(bill) { background-color: red; border: 2px solid green, } If you are referring to the cue settings part of styling, then those can be set on both, the region and the cue - the wiki page addresses what effect that has. >, there doesn't seem to > be a way to give their lifetime, That is true and intended in the current proposal. The idea is that a region hangs around for the duration of the video, always available to have cues be rendered into it should that be necessary. This also allows to avoid duplicating cue settings over and over again. It would, however, be possible to have regions defined/undefined and changed during the lifetime of the WebVTT file, such that, e.g. the region can be released, or moved to a different position on-screen. That would be a good extension to the current region spec. > and it duplicates a lot of the language > from regular cues to define the regions. True. It's a side effect of the need to have cue settings defined on both, cues and regions. > An alternative approach could be to have a way for a cue to say "add me to > this earlier cue, pushing up the data". It could look a bit like this: > > WEBVTT > > fred > 00:00:05.940 --> 00:00:10.610 > When I get a sick bird, > > 00:00:07.040 --> 00:00:11.700 continue:fred > that just stops everything > > Position information would go in the first cue, a cue with 'continue' would > just push its line(s) onto the bottom of the that cue, scrolling them up > accordingly. This is similar to another proposal that was earlier considered: http://www.w3.org/community/texttracks/wiki/RollupCaptions#4._Cue_setting:_grouping_cues . It is indeed simpler, but we had the following problems with this approach: * how would you define a maximum of three lines of rollup no matter if the individual cues are longer? * how would you style the rollup region in CSS, e.g. same background on all cues in it? * how would you style the rollup region separately from all the cues (there is a requirement in FCC for background styling of the region)? * how would you move all the cues in a rollup region together to a separate on-screen location should that be necessary as in this video: https://www.youtube.com/watch?v=F_q-RRXw-vY ? * if you have several rollup regions and they overlap, how do you replicate the CEA 708 feature to given them a z-index (called "layer")? Our conclusion of the discussion of the grouping approach was that it doesn't adequately represent the concept of a "rollup rendering area" (the equivalent of the CEA 708 "window" concept) and therefore causes all sorts of issues.
> The wiki page proposes to use a CSS pseudo-selector: My bad, I had read that then forgot about it when commenting here. > It is indeed simpler, but we had the following problems with this approach: > > * how would you define a maximum of three lines of rollup no matter if the > individual cues are longer? Why is this needed? The use case (comment 0 above) doesn't seem to require that authors have that control. > * how would you style the rollup region in CSS, e.g. same background on all > cues in it? Just have the cues be styled the same. > * how would you style the rollup region separately from all the cues (there > is a requirement in FCC for background styling of the region)? Where is that requirement? I thought I went through all the requirements and I don't recall seeing that. > * how would you move all the cues in a rollup region together to a separate > on-screen location should that be necessary as in this video: > https://www.youtube.com/watch?v=F_q-RRXw-vY ? You wouldn't, that's terribly confusing and doesn't seem to be required for the use case. > * if you have several rollup regions and they overlap, how do you replicate > the CEA 708 feature to given them a z-index (called "layer")? You wouldn't. That's not part of the use case; just having the overlap handled as we do now (in cue order) seems adequate to handle the use case.
The general idea is that while the FCC does not require some of the features for "windows", we actually want to support the full CEA 708 feature set and possibly more (such as rollup captions scrolling in the other direction). Still, some of the CEA 708 features are actually explicitly mentioned by the FCC. (In reply to comment #4) > > > > * how would you define a maximum of three lines of rollup no matter if the > > individual cues are longer? > > Why is this needed? The use case (comment 0 above) doesn't seem to require > that authors have that control. The FCC spec talks about a maximum of 4 lines present at any time. You could satisfy this need through making sure the caption encoder/author gets it right, but it's much easier on the WebVTT author (or converter) to be able to rely on such a setting to deal with any authoring mistakes. It also makes it possible to deal with this in the presence of word wrap. The region spec did that by defining a max height in number of lines. > > * how would you style the rollup region in CSS, e.g. same background on all > > cues in it? > > Just have the cues be styled the same. What would the CSS be for styling all cues in a continuation the same? > > * how would you style the rollup region separately from all the cues (there > > is a requirement in FCC for background styling of the region)? > > Where is that requirement? I thought I went through all the requirements and > I don't recall seeing that. I think it's a mis-interpretation of one of the FCC requirements that made you miss it: http://www.hallikainen.com/FccRules/2012/79/102/index.php (h) Window colors and borders. At a minimum, decoders must implement borderless windows with solid, black backgrounds ( i.e. , border type = NONE, fill color = (0,0,0), fill opacity = SOLID), and borderless transparent windows ( i.e. , border type = NONE, fill opacity = TRANSPARENT). This is talking about "windows" and not about "captions". The FCC (like CEA 708) separates between these two concepts and has background styling defined separately for both. I've been trying to point that out in the email thread before. > > * how would you move all the cues in a rollup region together to a separate > > on-screen location should that be necessary as in this video: > > https://www.youtube.com/watch?v=F_q-RRXw-vY ? > > You wouldn't, that's terribly confusing and doesn't seem to be required for > the use case. The goal of the FCC is to draw captions online in the same way that they were presented on TV. So it's a requirement. > > * if you have several rollup regions and they overlap, how do you replicate > > the CEA 708 feature to given them a z-index (called "layer")? > > You wouldn't. That's not part of the use case; just having the overlap > handled as we do now (in cue order) seems adequate to handle the use case. One of the biggest problems that we have with the way that overlap is handled with normal cues is that an author cannot force a caption to be rendered at an authored screen location - they are always at the whim of the cue replacement algorithm. This gives authors a way out: if they are really determined to place their caption at a given location and don't care about overlap (other than saying which caption is in front), the region spec gives them a solution. Another issue that I just remembered from implementation is the one of justification. If your cues are to be displayed in a centered fashion and you don't have the concept of a "region", how would you center all cues together in a specific subpart of the viewport, e.g. if you want them centered within the left half of the screen?
If the use case isn't what comment 0 described, it would be helpful if you could summarise the use case in the style given in comment 0 so that we can start from a clear use case and work from there, rather than changing the requirements continually as things are proposed.
Right. I am trying to clarify the "one or separate caption windows" wording in the use case in comment0 and how it is being used across FCC and CEA 708. It implies that rollup doesn't come by itself, but that it includes the concept of a rendering region for a group of captions and the separate formatting of that rendering region. It is still the use case in comment0 though.
Hmm. Does anything actually require multiple different captions to end up in the same widow? Maybe a simpler solution that satisfies the FCC requirements is just a new setting that applies to a single cue that takes a height value, and whatever settings you're supposed to be able to set, and it just scrolls the text of that cue up during the lifetime of the cue. No need to combine multiple cues or anything like that, no need for new CSS, no need to expose regions in the DOM, etc.
(In reply to comment #8) > Hmm. Does anything actually require multiple different captions to end up in > the same widow? I think so, yes. [1] defines what it understands by a roll-up caption window: "Caption window: The invisible rectangle which defines the top and bottom limits of a roll-up caption. The window can be 2 to 4 rows high. The lowest row of the window is called the base row." > Maybe a simpler solution that satisfies the FCC requirements is just a new > setting that applies to a single cue that takes a height value, and whatever > settings you're supposed to be able to set, and it just scrolls the text of > that cue up during the lifetime of the cue. No need to combine multiple cues > or anything like that, no need for new CSS, no need to expose regions in the > DOM, etc. I have tried to avoid the concept of "window" and piggy-back it as implicitly defined by the group of captions in the same location. However, I've found it to be much more complicated and not able to satisfy some needs. Two of the key concepts that are hard to do without such a concept: * distinguish the background color of the "window" from the background color of the individual cues (see FCC requirement in [1] § 79.103 (c) (6) and (8)) * moving all cues in a "window" together to a different location (see FCC requirement in [1]: "If the Preamble Address Code received contains a different base row than that of a currently displayed caption, the entire window will move intact (and without erasing) to the new base row immediately.") [1] http://cfr.regstoday.com/47cfr79.aspx
(In reply to comment #8) > Hmm. Does anything actually require multiple different captions to end up in > the same widow? > > Maybe a simpler solution that satisfies the FCC requirements is just a new > setting that applies to a single cue that takes a height value, and whatever > settings you're supposed to be able to set, and it just scrolls the text of > that cue up during the lifetime of the cue. No need to combine multiple cues > or anything like that, no need for new CSS, no need to expose regions in the > DOM, etc. I'm trying to apply this for a 1-hour video with roll-up captions: * This would mean a single cue for the whole video, with inner timestamps? * The settings would have to remain the same for the whole length of the video? * Changing the settings would imply creating a different cue? How is the new cue related with the one before, so that the previously displayed content doesn't get lost? * Wouldn't there be rendering conflicts, such as re-positioning the cue because of its changing size (and others discussed in rendering bugs)?
nessy: Thanks. Can I convince you to write a clear and concise summary of the requirements that the FCC rules have? I'm finding it very hard to do it myself, because they seem to span multiple documents and are really not written in a way I find easy to understand. With a clear set of requirements it would be easier for me to try to come up with the simplest solution that still solves the problem. vcarbune: Whatever we come up with, don't actually use it; the goal here is not to make it possible for authors to use scrolling captions, the goal is to make it possible to ship software that doesn't violate FCC rules. Scrolling captions are bad UI.
Hixie: I hear you! Multiple committees each with their own agenda - what can you expect! This is why I stick with looking at CEA-708, which all of the requirements can be traced back to. Ken wrote a nice summary of CEA-708 features once and I shared it at http://www.w3.org/community/texttracks/wiki/708Features . Does that help? Ultimately, I recommend looking at the original CEA-708 spec[1]. I can share that with you offline if you want to get your hands on it. If none of these work for you, I can certainly try to write a better requirements summary. Just let me know. [1] http://www.ce.org/Standards/Standard-Listings/R4-3-Television-Data-Systems-Subcommittee/CEA-708-D.aspx
Looking at CEA-708 doesn't help, because I wouldn't be able to tell which parts are legally part of the FCC requirements here and which parts are not. For example, I assume it's ok if we use UTF-8 rather than the wacked encoding CEA-708 uses, because I didn't see anything in the FCC regs about encodings. What I need at this point is a concise summary of the legal requirements that WebVTT doesn't meet, with a pointer to the precise paragraph of those requirements for each part of the summary so that I can see what the original wording was. I tried doing this (that's what led to this bug), but apparently I haven't done a sufficiently good job, so someone else should probably do it. Alternatively, we could do it the other way around: list all the applicable requirements, and then for each one cross it out if there's something in WebVTT that handles that requirement. What we'd be left with would be the requirements for this bug.
It's complicated to point to all the different regulations that the FCC has come up with, which all pick different CEA-708 feature sets to support. Would it be ok to list CEA-708 features that we (YouTube) have found are needed to support the FCC requirements?
Historically, people have listed requirements, and then when I've investigated, I've found they don't match what the FCC requirements actually are. So I really would much rather have the list of requirements clearly derived from the FCC requirements. I can do it myself if you want. Just list the URLs of all the pages that list requirements. I'll cross out everything that's already handled. What's left is what we need to handle for UA vendors who care about FCC requirements.
(In reply to comment #15) > Historically, people have listed requirements, and then when I've > investigated, I've found they don't match what the FCC requirements actually > are. So I really would much rather have the list of requirements clearly > derived from the FCC requirements. You can find most of the rulings at http://www.fcc.gov/document/closed-captioning-internet-protocol-delivered-video-programming-0 and http://www.fcc.gov/document/closed-captioning-internet-protocol-delivered-video-programming as well as the VPAAC reports at http://vpaac.wikispaces.com/ Why I keep focusing on CEA-708 features is because of this VPAAC report: http://vpaac.wikispaces.com/file/view/First+VPAAC+Report+to+the+FCC_7-11-11_FINAL.pdf "regardless of how the captioned video is transmitted and decoded, the consumer must be given an experience that is equal to, if not better than, the experience provided as the content was originally aired on television using the CEA-608/708 system." All the other explicitly listed requirements in the FCC are derived from this and therefore the easiest is to just represent all CEA-608/708 rendering requirements (char sets can be converted without loss). However, we are running out of time: http://www.fcc.gov/guides/captioning-internet-video-programming We need to start implementing and can't go through another round of requirements collection, in which every round brings you one more insight. The "region" spec proposal has been the result of many discussions on the mailing list by the community, a discussion of many alternative specifications, input from many caption experts offline, a trial implementation in JavaScript, and a trial implementation in YouTube, where the problems discovered in the implementations have been fed back to the spec. In your "process for adding new features" FAQ [1] we are now at step 7 and I don't want us to go back to 1, in particular given that your objections to the "region" spec in comment2 were not substantial. We should therefore move on to step 8 and use a spec that has not only been created by people that want to use that feature, but that has already been implemented and proven to work. When browser implementations of the "region" spec have been successful and interoperable, that will be the time for you to update the spec. This will save us all a lot of time right now. [1] http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
"equal to, if not better than" is easy. Not scrolling is better than scrolling. I'll go through the links you provided and try to list all the requirements, then cross out the ones that are handled already.
There's a zillion links on http://vpaac.wikispaces.com/ — which specific ones give requirements that apply to you?
Incidentally, if the content we're worried about is all currently published with CEA-708 captions, and the FCC rules are basically just requiring that we implement all the CEA-708 features, is there a reason we couldn't just implement CEA-708? That seems like it'd be the simplest way of making sure we unambiguously achieve compatibility, and that format seems relatively straight-forward (after all, even small TVs can implement it).
(In reply to comment #17) > "equal to, if not better than" is easy. Not scrolling is better than > scrolling. That's a very subjective assessment of quality. The way in which time-overlapping cues are painted right now where they will find the first free spot in the default location to paint into is in my opinion worse quality than scrolling. I think you will find just as many people that agree with my assessment as people that disagree me (and agree with you). More importantly though the people that wrote that sentence are in my half of the boat, so scrolling is a feature that is expected to be replicated. (In reply to comment #18) > There's a zillion links on http://vpaac.wikispaces.com/ — which specific > ones give requirements that apply to you? See comment #14 . (In reply to comment #19) > Incidentally, if the content we're worried about is all currently published > with CEA-708 captions, and the FCC rules are basically just requiring that > we implement all the CEA-708 features, is there a reason we couldn't just > implement CEA-708? That seems like it'd be the simplest way of making sure > we unambiguously achieve compatibility, and that format seems relatively > straight-forward (after all, even small TVs can implement it). I hope you're not serious about this. This would be the first caption format that we expect a browser to implement that is not a text format but basically binary [1] and can't be authored by hand. The conversion doc from CEA608/708 to WebVTT is not that complicated [2] and most features are covered. All we need in WebVTT is a means to group cues together so we can move them in one group, determine the scrolling region, determine their scrolling speed, and determine the group background color and border. The "region" proposal [3] satisfies these needs. [1] http://www.theneitherworld.com/mcpoodle/SCC_TOOLS/DOCS/SCC_FORMAT.HTML [2] https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html [3] http://www.w3.org/community/texttracks/wiki/MultiCueBox
I was actually completely serious. Why would it being non-text matter? The whole point would be to take the data straight from the broadcast and just render that — no need for any conversion to WebVTT at all. This really seems like a far better solution than trying to add features to WebVTT purely to make the FCC happy.
(In reply to comment #21) > I was actually completely serious. Why would it being non-text matter? The > whole point would be to take the data straight from the broadcast and just > render that — no need for any conversion to WebVTT at all. > > This really seems like a far better solution than trying to add features to > WebVTT purely to make the FCC happy. It's unfortunate that in your eyes the only valid reason for existence of rollup captions on the Web is the FCC ruling when there are plenty of people that want to author rollup captions not just to make the FCC happy. They want them in WebVTT. Also, as I said, we are running out of time and I simply can't see browsers implementing CEA-708.
(In reply to comment #21) > I was actually completely serious. Why would it being non-text matter? The > whole point would be to take the data straight from the broadcast and just > render that — no need for any conversion to WebVTT at all. This requires more work for browsers than simply extending WebVTT with Silvia's proposal. > This really seems like a far better solution than trying to add features to > WebVTT purely to make the FCC happy. There are authors that actually want to use these features not just because of being compliant with FCC. It feels like a step backwards to force both browsers and such authors to implement decoders and encoders, respectively, for CEA-708.
Authors wouldn't have to use new encoders. The data we're talking about is already encoded, using that very format. And it's a simple format to support, that's kind of it's whole reason for being — it was designed for low-power devices. If there are other reasons than FCC compliance for scrolling captions, then file bugs on those use cases. So far, all those use cases have been highly unconvincing, with actual studies showing that scrolling captions is just bad UI. I think it would be harmful to the Web to add scrolling to WebVTT, as it would send the message to authors that it's not a bad feature. I think supporting the CEA-708 format as a secondary format to satisfy the FCC requirements is the way to go. It's relatively straight-forward, doesn't need much in the way of integration into HTML (e.g. we don't need to expose the cue text), and it's by far the simplest solution for authors with that content. Plus, it has the advantage of it being already accepted that that format does satisfy the FCC, so there's no second-guessing ourselves about what the requirements are.
(In reply to comment #24) > I think it would be harmful to the Web to add scrolling to WebVTT, as it > would send the message to authors that it's not a bad feature. This continues to be your personal opinion and not something that the captions community agrees with. The caption community wants an extension to WebVTT to be able to author rollup captions and to display them in Web browsers. I have created a WebVTT specification extension for the "region" feature at https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/region.html
Note: Since regions are now implemented in blink and partially implemented in WebKit, I am preparing to merge the extension specification.
(In reply to comment #26) > Note: Since regions are now implemented in blink and partially implemented > in WebKit, I am preparing to merge the extension specification. I would wait until it's at least behind an experimental flag in Blink so that people can try it out.
(In reply to comment #27) > (In reply to comment #26) > > Note: Since regions are now implemented in blink and partially implemented > > in WebKit, I am preparing to merge the extension specification. > > I would wait until it's at least behind an experimental flag in Blink so > that people can try it out. I'd much prefer that it's integrated, so we have one integrated spec. that we're all working to. That also allows us to check there aren't any integration issues. Is there any practical value to holding off?
(In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #26) > > > Note: Since regions are now implemented in blink and partially implemented > > > in WebKit, I am preparing to merge the extension specification. > > > > I would wait until it's at least behind an experimental flag in Blink so > > that people can try it out. > > I'd much prefer that it's integrated, so we have one integrated spec. that > we're all working to. That also allows us to check there aren't any > integration issues. > > Is there any practical value to holding off? Well, I just thought that the fact that an implementation exist is actually relevant only because it implies that it can be tested (which isn't true without this experimental flag). Other than that, I support the integration of the spec into WebVTT.
(In reply to comment #29) > (In reply to comment #28) > > (In reply to comment #27) > > > (In reply to comment #26) > > > > Note: Since regions are now implemented in blink and partially implemented > > > > in WebKit, I am preparing to merge the extension specification. > > > > > > I would wait until it's at least behind an experimental flag in Blink so > > > that people can try it out. > > > > I'd much prefer that it's integrated, so we have one integrated spec. that > > we're all working to. That also allows us to check there aren't any > > integration issues. > > > > Is there any practical value to holding off? > > Well, I just thought that the fact that an implementation exist is actually > relevant only because it implies that it can be tested (which isn't true > without this experimental flag). When do you expect the experimental flag? Also, isn't the blink community normally waiting for features being in the spec before releasing the feature?
I've merged the region spec into the webvtt spec. This was a rather massive merge, so please report bugs. The merged spec is available at: https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/webvtt.html The previous spec version is still at: http://dev.w3.org/html5/webvtt/
Can you link to the relevant changes in https://dvcs.w3.org/hg/text-tracks/shortlog ?
Basically it's all changes since "Added region example to Introduction section under "Other features"." https://dvcs.w3.org/hg/text-tracks/rev/fe510aaf4b7b I worked through the spec section by section. Would you prefer to look at an actual patch? Note: I have also made the syntax section a bit more accessible by defining more sections that I think are relevant to authors.