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

On Tue, May 6, 2014 at 4:45 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> On 06/05/2014 14:17, "Philip Jägenstedt" <philipj@opera.com> wrote:
>
>>On Tue, May 6, 2014 at 12:19 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>>wrote:
>>>
>>> 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:
>>>>
>>>>> 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.
>>
>>So, my question was actually rhetorical. I don't think it should be a
>>goal in itself to map other formats to WebVTT, or for WebVTT to be one
>>format to rule them all.
>
> Sorry I didn't spot the <rhetorical> tag! In any case there is a point to
> discuss there. I agree that format mapping isn't an end in itself, but in
> this case we know that some form of mapping will be generated and we can
> aim to make life easier by reducing the size of the task. To be clear,
> there is a TTWG goal to map between WebVTT and TTML - it is in the group's
> charter.

If the required changes are trivial or are supported by common use
cases then that would be valuable feedback like any other. It is
making non-trivial changes for no other purpose than format mapping
that I am wary of, because it is a road with no apparent end, and one
that we don't need to walk if we take advantage of the fact that
WebVTT is a part of the Web platform where less common use cases (a
judgement call) can be left to custom rendering using JavaScript.

>>If other formats have features that address common use cases that
>>WebVTT is missing then we should consider supporting those use cases,
>>of course.
>
> I get the impression this is about FCC-mandated requirements rather than
> usage frequency. It makes sense to do as little as possible to meet those
> requirements and expand & enhance later if people want to use it in new
> ways. Lifting the existing region model from TTML would probably fit that
> description.

As far as I am aware the FCC doesn't require using a specific
technology to meet the requirements. However, I'm having trouble
getting clear answers on this topic from legal, and don't know the
plans of any browser company.

Philip

Received on Tuesday, 6 May 2014 22:20:55 UTC