Re: Absolute region positioning (was Re: Alternative approach to scrolling, with demos)

On 05/05/2014 15:14, "Philip Jägenstedt" <philipj@opera.com> wrote:

>On Mon, May 5, 2014 at 2:50 PM, Silvia Pfeiffer
><silviapfeiffer1@gmail.com> wrote:
>> On Mon, May 5, 2014 at 10:16 PM, Philip Jägenstedt <philipj@opera.com>
>>wrote:
>>> On Mon, May 5, 2014 at 1:38 PM, Silvia Pfeiffer
>>> <silviapfeiffer1@gmail.com> wrote:
>>>> On Mon, May 5, 2014 at 9:17 PM, Philip Jägenstedt <philipj@opera.com>
>>>>wrote:
>>>>> On Tue, Apr 8, 2014 at 9:21 AM, Silvia Pfeiffer
>>>>> <silviapfeiffer1@gmail.com> wrote:
>>>>>> On Sun, Mar 30, 2014 at 4:41 PM, Philip Jägenstedt
>>>>>><philipj@opera.com> wrote:
>>>>>>>
>>>>>>> == Absolute positioning and scrolling ==
>>>>>>>
>>>>>>> Demo:
>>>>>>>http://people.opera.com/philipj/2014/03/vttscroll/absolute.html
>>>>>>>
>>>>>>> Finally, an idea for how scrolling might work with absolutely
>>>>>>> positioned cues. You simply position all the cues at the point
>>>>>>>where
>>>>>>> scrolling should begin, and they'll scroll up from there.
>>>>>>
>>>>>> I've attached a vtt file for you with two "regions". The cues should
>>>>>> each get limited to their "region".
>>>>>>
>>>>>> You can see for yourself how this breaks down with 2 regions
>>>>>>present.
>>>>>>
>>>>>> I think it's quite clear that the concept of cue groups codified in
>>>>>> regions is a more appropriate approach than building ad-hoc groups
>>>>>>of
>>>>>> captions by trying to group them based on them overlapping each
>>>>>>other.
>>>>>
>>>>> For simplicity in the demo, I scrolled all the cues by the same
>>>>>amount
>>>>> without checking if they actually overlap, which of course falls
>>>>>apart
>>>>> when you have two groups of cues. If implemented properly, I don't
>>>>>see
>>>>> that cues scrolling in different parts of the video would be a
>>>>> problem. If scrolling implemented as overlap avoidance, the situation
>>>>> has to be handled anyway.
>>>>>
>>>>> How are overlapping regions handled? Not at all AFAICT, some text
>>>>> would simply be obscured.
>>>>
>>>> Indeed, we're not currently handling overlapping regions. I don't
>>>> think we need to either, because not even CEA708 has an overlap
>>>> avoidance algorithm. Instead, it specifies z-index (called "priority")
>>>> so the author can determine which cue sits in front if overlap
>>>> happens.
>>>>
>>>> I don't mind that actually, because it provides an alternative to the
>>>> default cues which do overlap avoidance.
>>>
>>> I do mind. Why should we accept this deficiency just because CEA708
>>> has it? Unless the video is entirely filled with text (unlikely) there
>>> will be a way to show all of it without overlap, so why not deal with
>>> the situation since WebVTT already has overlap avoidance?
>>
>> I don't see it as a deficiency. I actually think it's a strength
>> knowing exactly where ones content ends up being rendered on screen
>> without the browser interfering with positioning. What if I'd like to
>> author my cues such that they overlap? Maybe it's because it's the
>> lesser evil than overlapping other content on the screen? I really
>> think we may be over engineering the overlap avoidance issues if we're
>> trying to avoid overlap at all cost.
>
>If we tried to add overlap avoidance to the CEA708 model at any cost I
>would probably agree, that could turn into a mashup of two models that
>doesn't make sense. However, the approach I was taking with my demo
>was trying to solve the use cases by using the existing overlap
>avoidance. Matching CEA708 semantics wasn't the goal, and I guess
>that's the crux of the issue...
>
>> NB: Incidentally, following CEA708 rendering as exactly as possible is
>> inline with what the US law prescribes, namely identical rendering
>> between TV and Online. Though, to be honest, there is a line of "rough
>> identity" that I am prepared to accept and I would call overlap
>> avoidance an optimisation of sorts, which is why I'm not really
>> accepting this as an argument.
>
>What will we do if the European Union introduces similar legislation
>and broadcasters say that their existing content is EBU-TT, a TTML
>flavor? Should the TTML model be added to WebVTT?

I don't know about adding the TTML model precisely but I do think it would
be worth considering the logical semantics encapsulated in TTML for region
definition and overlap processing, which has an accepted mapping from
CEA708 already, and has therefore tackled these questions. Given that
WebVTT is on Rec track in the TTWG and one of the deliverables is a VTT
<--> TTML mapping it would make everyones' lives easier in creating that
deliverable if the regions models are as closely coincident as we can make
them, accepting the differences in rendering approach and syntax between
the two formats.

I haven't seen anything in the discussion so far that looks like a CEA708
requirement that can not already be met using TTML regions. If you want
region overlap avoidance that would be different, but I suspect that isn't
actually needed, and in any case would be a separate case from the z-index
overlap order definition: I can't see how both approaches could apply to
the same content simultaneously.

Nigel

>
>In Sweden, live news programs use the teletext system for captioning,
>and erasures to fix typos are rather common. This feature is also
>supported by 608, described in the section "Backing Up and Making
>Corrections" in "The Closed Captioning Handbook". Should it be added
>to WebVTT?
>
>I guess I just don't understand what the criteria for adding new
>features to WebVTT should be...
>
>Philip
>



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Tuesday, 6 May 2014 10:20:06 UTC