Re: Unifying the rendering approach

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.

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.

Nigel


On 24/01/2014 05:26, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:

>Hi all,
>
>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 Friday, 24 January 2014 10:08:04 UTC