Re: Unifying the rendering approach

Hi Nigel,


On Fri, Jan 24, 2014 at 9:07 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> The general problem with allowing the client to position cues that overlay
> other visual content, e.g. video,is that this does not take into account
> information that the viewer needs from that visual content itself. For
> example many hard of hearing users of captions need to see the mouths of
> people talking as well as the caption text. And some video content
> contains burnt-in text that is essential for understanding the programme.
> Traditionally this is managed by editorial effort to position the captions
> carefully at the authoring stage, at least in those formats that permit
> positioning data to be expressed.

Right. So, the idea is that if the content was authored well, the
rendering in the browser will never have to deal with overlap
avoidance.

However, not all content is authored well. For example content is
authored for a specific font size. If that font size is increased by
the user, or by a custom style sheet, the browser still should do its
best to render content in such a way that it's readable. If it can
move lines slightly and thus avoid overlap, surely that's preferable
to captions that overlay each other.


> Since in this scheme it may not be possible to honour the author's
> positive intentions re positioning it may be useful to consider an
> alternate mechanism in which the author states negatively those regions
> that should not be overwritten by any rendered cues. If this can be built
> into the overlap avoidance algorithm that would be extremely helpful for
> ensuring all viewers are able to watch the content.

Right, I agree it would be better to create a kind of "mask" track
that defines areas and time on the video where nothing should be
overlayed. Such a track would move all cues of all other tracks out of
the way. I think this could be done as a separate track (could be a
WebVTT track) that just has empty but positioned cues with exact
dimensions. This could be part of a overlap avoidance scheme that is
done on the video level and works across all tracks.

I don't really think we should deal with that on the individual track
level though.

I'd be curious to hear others opinions. I don't really have any good
ideas for overlap avoidance, but I don't really like what we currently
do, since I think it's unnecessarily complicated - and most certainly
we have to find an integrated way for regions and non-region cues. Any
suggestions welcome.

> Nigel

Apart from Nigel's input, I'd also like to hear any other concerns
about placing non-region cues into anonymous regions as suggested.
Is overlap avoidance really the only issue that we need to discuss
when we unify the rendering section?

Thanks,
Silvia.


> On 24/01/2014 05:26, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:
>
>>Hi all,
>> a
>>The introduction of regions created a second code path in the
>>rendering spec with some duplication.
>>
>>At FOMS, several people voiced that they are unhappy about it.
>>We discussed if it was possible to unify that.
>>
>>The proposal that we came up with was to put *all* cues into regions.
>>A region is thus basically the background box into which cues are
>>rendered.
>>
>>Cues that have no region reference will be put into an anonymous
>>region that has:
>>* no identifier,
>>* the dimensions of the viewport (vw, vh),
>>* no scroll,
>>* a region anchor of (0,100),
>>* a region viewport anchor of (0,100).
>>
>>The intent is to allow us to create a single rendering path for all cues.
>>
>>However, there are differences between cues that are currently
>>rendered without a region and those that are rendered into a region
>>and we have to work these out. We can either try to retain the
>>previous behaviour or come up with a better, more integrated way of
>>doing it.
>>
>>So, I've gone through and tried to identify the differences.
>>
>>* overlap avoidance: cues without a region have a means to deal with
>>overlap and move cue positions. The approach here is different between
>>snap-to-line positioned cues and percentage positioned cues. I'd like
>>to come up with an algorithm that deals the same with all cues. Also,
>>it needs to be deterministic for the JavaScript developer so they can
>>potentially do even more repositioning if necessary. So, my thoughts
>>are that we should just avoid placing cues into lines (for horizontal
>>cues; rows for vertical cues) that are already occupied by another
>>cue. That's basically the algorithm for snap-to-line positioned cues.
>>It wouldn't apply to scrolling regions, but to all other ones.
>>
>>(BTW: I think we need two levels of overlap avoidance: one within a
>>track and one that optimizes between all tracks, not just VTT tracks.
>>So, we may need to create an algorithm for the HTML spec for this,
>>too. But this is a discussion for another day.)
>>
>>* snap-to-lines: cues in a region don't have snap-to-lines
>>positioning. When we place such cues into anonymous regions, we
>>calculate the number of lines from the size of the region, which for
>>an anonymous region is the size of the viewport. So, this should be
>>fine.
>>
>>* title area: right now we have a means to specify a "title area" for
>>snap-to-lines cues. I think we can remove that because we now have
>>padding on the cue background box (which will be the region in
>>future), so we have that covered for all types of cues.
>>
>>
>>Are there any other issues I have overlooked?
>>
>>
>>Thanks,
>>Silvia.
>>
>
>
>
> -----------------------------
> 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 Monday, 27 January 2014 02:23:56 UTC