Re: Unifying the rendering approach

On Tue, Feb 18, 2014 at 8:11 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> On 18/02/2014 09:04, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:
>
>>On Tue, Feb 18, 2014 at 7:55 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>>wrote:
>>> On 18/02/2014 07:48, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
>>>wrote:
>>>
>>>>Here are some examples.
>>>>
>>>>1. Regular cues without region reference:
>>>>
>>>>These are the cues that were previously not rendered into a region,
>>>>but would now be rendered into an anonymous region.
>>>>
>>>>Example file
>>>>---
>>>>WEBVTT
>>>>
>>>>Cue 1
>>>>0:00:03.040 --> 0:00:15.302
>>>>So, I just wanted to introduce you to W3C,
>>>>
>>>>Cue 2
>>>>0:00:06.920 --> 0:00:15.302
>>>>and to do so, I have some exciting information:
>>>>
>>>>Cue 3
>>>>0:00:10.000 --> 0:00:15.302
>>>>W3C has been acquired by Twitter.
>>>>
>>>>Cue 4
>>>>0:00:13.800 --> 0:00:15.302 position:5%,start align:start size:30%
>>>>line:5%,start
>>>>[AUDIENCE GIGGLES]
>>>>---
>>>>
>>>>Rendered at time 15.300 as in the attached regular_cues.png .
>>>>
>>>>This is the same rendering as we had before doing regions (keeping
>>>>backwards compatibility). There is a single anonymous region and it
>>>>contains all cues that are not associated with a named region. The
>>>>region always covers the full viewport. Cues inside it try to avoid
>>>>overlaps (how is yet to be clarified - for now let's assume it's done
>>>>as before introducing an anonymous region). This is why cues 2 and 3
>>>>move above their default position which is already occupied by cue1.
>>>>
>>>>
>>>>2. Cues in a named region that is not scrolling:
>>>>
>>>>These are cues that are rendered into a region, but the region is
>>>>non-scrolling.
>>>>
>>>>Example file
>>>>---
>>>>WEBVTT
>>>>Region: id=region1 width=50% lines=3 regionanchor=0%,100%
>>>>viewportanchor=0%,100%
>>>>Region: id=region2 width=30% lines=1 regionanchor=0%,0%
>>>>viewportanchor=5%,5%
>>>>
>>>>Cue 1
>>>>0:00:03.040 --> 0:00:15.302 region:region1 align:left
>>>>So, I just wanted to introduce you to W3C,
>>>>
>>>>Cue 2
>>>>0:00:06.920 --> 0:00:15.302 region:region1 align:left
>>>>and to do so, I have some exciting information:
>>>>
>>>>Cue 3
>>>>0:00:10.000 --> 0:00:15.302 region:region1
>>>>W3C has been acquired by Twitter.
>>>>
>>>>Cue 4
>>>>0:00:13.800 --> 0:00:15.302 region:region2
>>>>[AUDIENCE GIGGLES]
>>>>---
>>>>
>>>>Rendered at time 15.300 as in the attached region_noscroll_cues.png .
>>>>
>>>>This has two regions that are both filled from the bottom line upwards
>>>>(just like the previous case). The regions are fixed in size through
>>>>the lines region setting. They are anchored so that if the font size
>>>>changes, it's easy to see where the region and cues grow from. The
>>>>first two lines in region1 are left aligned, the third is middle
>>>>aligned within region1, the fourth is middle aligned within region2
>>>>(middle alignment is default for cues). I could have used a "line"
>>>>setting on the cues to determine which line within their region cues
>>>>would be rendered into. In that way, I could have started rendering
>>>>cues in the top line then successively fill the two lines below in
>>>>region1 (that would be: line:-1, line:-2, line:-3 or line:2, line:1,
>>>>line:0 just as before for cues without region except the numbering is
>>>>applied within the region rather than the viewport).
>>>>
>>>>
>>>>3. Cues in a named region that is scrolling:
>>>>
>>>>These are cues that are rendered into a rollup (scrolling) region.
>>>>
>>>>Example file
>>>>---
>>>>WEBVTT
>>>>Region: id=region1 width=50% lines=3 regionanchor=0%,100%
>>>>viewportanchor=0%,100% scroll=up
>>>>Region: id=region2 width=30% lines=1 regionanchor=0%,0%
>>>>viewportanchor=5%,5% scroll=up
>>>>
>>>>Cue 1
>>>>0:00:03.040 --> 0:00:15.302 region:region1 align:left
>>>>So, I just wanted to introduce you to W3C,
>>>>
>>>>Cue 2
>>>>0:00:06.920 --> 0:00:15.302 region:region1 align:left
>>>>and to do so, I have some exciting information:
>>>>
>>>>Cue 3
>>>>0:00:10.000 --> 0:00:15.302 region:region1
>>>>W3C has been acquired by Twitter.
>>>>
>>>>Cue 4
>>>>0:00:13.800 --> 0:00:15.302 region:region2
>>>>[AUDIENCE GIGGLES]
>>>>---
>>>>
>>>>Rendered at time 9.000 as in the attached region_scroll_cues.png .
>>>>
>>>>This has two regions that are both allowing cues to be scrolled. The
>>>>regions are fixed in size through the lines region setting, but are
>>>>squashed to height 0 until cues are actually added. That can be seen
>>>>easily in the picture for region2 (since it's at time 9.000). In
>>>>region1, we have thus far rendered 2 cues. They are added one by one,
>>>>starting in the bottom most line and moving "up". This is why cue 1 is
>>>>in line 2 of region1 and cue 2 is in line 3.
>>>>
>>>>======
>>>>
>>>>While preparing these examples, I noticed that some contradict the way
>>>>current regions are defined. In particular we need to change the
>>>>following:
>>>>* the spec currently says that cues in region are added one line at a
>>>>time below existing cue lines -> this will need to be conditioned on
>>>>the cue being in a scrolling region only
>>>>* the spec currently prohibits "line" settings on cues in regions -
>>>>this should be allowed for cues that are not in scrolling regions
>>>>
>>>>Once that is done, the rendering of non-scrolling regions and
>>>>anonymous regions is identical with only scrolling regions having some
>>>>special rules. That should make it easier to consolidate the rendering
>>>>section. Have I overlooked any corner cases?
>>>
>>> What happens when the rendered cue text doesn't fit on a single line, or
>>> if wrapped to multiple lines occupies more lines than the region can
>>> stretch to? Does the scrolling behaviour influence the output?
>>
>>Yes, if scrolling is enabled, the oldest line will scroll out of view.
>>If no scrolling is enabled, it's possible that some lines of the newly
>>rendered cue overflow and thus are not visible.
>
> If a single cue does not wholly fit within the region and scrolling is
> enabled, so that there's no 'oldest' cue, will the implementation be
> expected to make an attempt to show all of the lines in turn until all
> have been displayed?

The lines will scroll up one at a time, but if the region is
restricted to 3 lines and the cue occupies 4, then the first line will
disappear. I believe that would be the same in CEA-708, which was the
model for how we defined regions.


> Assuming 'yes' to this, are there timing constraints
> to define the minimum visibility duration for each line prior to it being
> scrolled out of the visible area?

Scrolling happens with a CSS transition whose duration is defined to
be 0.433s, which is the value that CEA-708 prescribes. Is that what
you're asking for?

> I mean in the WebVTT, globally or per
> cue, rather than in the spec. The use case for this is to maintain a
> maximum required reading rate (words per minute), which is likely to be
> content dependent.

Understood. This is a corner case of poor authoring, which I believe
isn't taken care of in CEA708 either. Feel free to correct me or to
suggest a different approach. What does TTML do in this case?

Cheers,
Silvia.

Received on Tuesday, 18 February 2014 10:35:25 UTC