RE: Action-201 and Issue-225

Dear Mike, All,

Just for your information ☺… within the EBU-TT group we have had lengthy discussions about pixels and aspect ratios.

In EBU-TT, the root container is directly mapped to the full extent of the active video area of a presentation. There is an underlying assumption that the video used at authoring has a 1:1 correspondence with the presentation (in both temporal and visual terms).
Consequently, using pixels in an EBU-TT document has a restricted meaning. In effect pixels become simply a subdivision or unit of the root container.

Clearly you can define the extent of the root container using pixels, but the values chosen for extent may not equate to the actual video resolution… for example you could define extent as 1440 x 1152, but the matching presentation resolution might be 720 x 576 (D1).
In this case there is an implicit 2:1 scaling between pixel dimensions used within the EBU-TT document and the actual presented pixels the viewer might see.

Aspect ratio in EBU-TT is actually irrelevant, since we conceptually always draw on the video canvas and measure our content using units pinned to that context. Thus our content ‘stretches to fit’ the active video canvas. It is accepted that there is no mechanism within EBU-TT to ensure that a circle remains a circle upon presentation… this is considered to be ‘out of scope’ for EBU-TT. It is more important to retain a 1:1 correspondence between a subtitle pixel and a picture pixel than to retain a ‘correct aspect ratio’.

However, to support downstream manipulations of the video we also provide a mechanism within EBU-TT to signal various metadata about the assumed context. This metadata includes the aspect ratio of the underlying video and information about any black bars (letter box or pillar box) present in the video. The rationale for including this information is that downstream processes may alter the video context (for example removing black bars from the video, pan scan or centre crop etc.). By providing metadata about letter boxing and A/R, a downstream process can determine the positions of subtitle content with respect to the active picture presentation. The downstream process is thus equipped to make informed decisions about re-positioning subtitle content to retain or modify this positioning. This last point might need clarification. In EBU-TT the extent is the active video, but the content position can (by using optional metadata) effectively be determined (by a downstream processor) with respect to the active picture (which may be smaller than the active video).

I accept that in the wider sphere of TTML it may be necessary to support authoring in a context that is independent of the target context, and also to describe how the authoring context is transformed into the presentation context, but for subtitling applications I do not believe this is necessary.

Best regards,
John

John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 270 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems


Visit us at
IBC, Hall 1 Stand C49, The RAI, Amsterdam, 13-17 September

P Before printing, think about the environment

From: Michael Dolan [mailto:mdolan@newtbt.com]
Sent: 06 September 2013 20:01
To: 'Timed Text Working Group'
Subject: RE: Action-201 and Issue-225

Sorry to miss the last half of the call yesterday, so maybe this was addressed.  But before we talk more about pixels, don’t we need to first extract ourselves from the normative definition of px being related only to the decoder physical display? I’m not opposed to adding pixel aspect ratio, but aspect ratio of what?  I think current applications actually ignore this today and define an authoring coordinate system.  In the case of DECE, it is 1 coded sample of the related video object. It is often non-square.

See highlight below for TTML1SE.

                Mike


TTML1SE, 8.3.12 <length>

The semantics of the unit of measure px (pixel) are as defined by [XSL 1.1]<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#xsl11>, § 5.9.13

XSL 1.1, 5.9.13.1 Pixels

XSL interprets a 'px' unit to be a request for the formatter to choose a device-dependent measurement that approximates viewing one pixel on a typical computer monitor. This interpretation is follows:

1.    The preferred definition of one 'px' is:

o    The actual distance covered by the largest integer number of device dots (the size of a device dot is measured as the distance between dot centers) that spans a distance less-than-or-equal-to the distance specified by the arc-span rule in http://www.w3.org/TR/REC-CSS2//syndata.html#x39<http://www.w3.org/TR/REC-CSS2/syndata.html#x39> or superceding errata.

o    A minimum of the size of 1 device dot should be used.

o    This calculation is done separately in each axis, and may have a different value in each axis.

2.    However, implementors may instead simply pick a fixed conversion factor, treating 'px' as an absolute unit of measurement (such as 1/92" or 1/72").

Note:

Pixels should not be mixed with other absolute units in expressions as they may cause undesirable effects. Also, particular caution should be used with inherited property values that may have been specified using pixels.

If the User Agent chooses a measurement for a 'px' that does not match an integer number of device dots in each axis it may produce undesirable effects, such as:

·         moiré patterns in scaled raster graphics

·         unrenderable overlapping areas when the renderer rounds fonts or graphics sizes upward to its actual dot-size

·         large spaces between areas when the renderer rounds fonts or graphics sizes downward to its actual dot-size

·         unreadable results including unacceptably small text/layout (for example, a layout was calculated at 72 dpi [dots per inch], but the renderer assumed the result was already specified in device dots and rendered it at 600 dpi).

Stylesheet authors should understand a pixel's actual size may vary from device to device:

·         stylesheets utilizing 'px' units may not produce consistent results across different implementations or different output devices from a single implementation

·         even if stylesheets are expressed entirely in 'px' units the results may vary on different devices


Regards,

                Mike

From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: Friday, September 06, 2013 2:57 AM
To: Timed Text Working Group
Subject: Action-201 and Issue-225

In the absence of automated change notifications from the action and issue tracker, here is a manual notification that I've updated Issue-225<http://www.w3.org/AudioVideo/TT/tracker/issues/225> as per my Action-201 from yesterday. The update to Issue-225 is:


As per action-201<http://www.w3.org/AudioVideo/TT/tracker/actions/201> [1], I've looked to see if pixel aspect ratio would or should affect the meaning of vmin and vmax.

[1] https://www.w3.org/AudioVideo/TT/tracker/actions/201


It is possible to construct an example where taking pixel aspect ratio in to account to calculate actual dimensions would give a different result from omitting it. However the root definition of vmin and vmax, in [2], is unclear or at best non-specific about the intended behaviour. It appears to depend on how the viewport size itself was defined, i.e. if in physical units then vmin and vmax should relate to those physical sizes but if in pixels then vmin and vmax should relate to the pixel dimensions.

[2] http://www.w3.org/TR/css3-values/#viewport-relative-lengths


In TTML we only define a logical coordinate plane but we do allow ttp:pixelAspectRatio to be defined. I think there is very likely a use case for referring to the minimum or maximum size after pixelAspectRatio conversion to relate these terms to 'real' sizes. Certainly this should be considered and made explicit in the definition of the attributes.

For reference, here's one contrived example in which vmin and vmax have different values depending on whether the extent is multiplied by the pixelAspectRatio before the min/max decision or after it. Take an extent of 400w x 300h and a pixel aspect ratio of "1 1.5". Before conversion vmin=300/100 and vmax=400/100. Taking pixelAspectRatio into account, the min/max choice is between 400x1=400 and 300x1.5=450, and the decision is made the other way, so, after returning to our extent coordinate system, vmin=400/100 whereas vmax=300/100.

The question comes down to whether vmin and vmax apply numerically to our extent or is intended to compare actual sizes.

Nigel Megitt, 6 Sep 2013, 09:44:24


I've also updated Action-201 and set it to Pending Review.

Kind regards,

Nigel

--

Nigel Megitt
Lead Technologist, BBC Technology, Distribution & Archives
Telephone: +44 (0)208 0082360
BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP




----------------------------

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.

---------------------

This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ