Root Container Region and Safe-Title Area

[adam-gol]

@mikedo and I were discussing (my alleged) lack of specificity in the standards about whether the IMSC1 document is or is not required/recommended to keep captions within the safe title area or not. I cannot find clear text which indicates that an IMSC1 document should only place text within the safe title area, and I do find indication that it need not.

There's a suggestion that perhaps IMF makes this requirement/recommendation. I don't think it does. Below, a set of standards that seem pretty clear that the root container region be the whole visible screen, but nowhere does it limit the use of that region to be the safe-title portion of it.

Constraining to the US, and constraining to CTA-608/708, the FCC makes requirements about how much text the receiver is required to be capable of displaying within the safe-title area, and it's clear that 608/708 captions are authored expecting that any screen area addressable using the 608/708 mechanisms is within the safe-title area. In an imsc1 context, where most (television) captioning is initially authored in 608 and then converted, it seems possible that the conversions process is aware that the 608/708 area is smaller than the root container region and specifically makes allowances for that (by producing imsc1/ttml that avoids the area outside the safe title area). However, I can't find that as a requirement (or even a recommendation) for 608/708 conversions anywhere. Additionally, for imsc1/ttml-native content, there's similarly to requirement that I can find (and it's difficult to even infer it the way you can with 608/708 converted content). Therefore, t's difficult to both comply with an FCC expectation that captions are only displayed inside the safe title area and that imsc1/ttml is capable of causing captions to be rendered outside the safe title are.

Help? (Or is this better directed to a SMPTE audience?)

ST 2067-2:2020
5.4.7 Mapping of the Root Container Region
The Root Container Region of the Document Instance shall be mapped to the Display Rectangle (defined by SMPTE ST 377-1) of the Main Image Virtual Track.

ST 377-1:2019
G.1.3 Display Rectangle
The Display Rectangle shall be the rectangular region which is visible in the display device

So therefore: “ The Root Container Region of the Document Instance shall be mapped to the rectangular region which is visible in the display device.”

ttml1:
Root Container Region
A logical region that establishes a coordinate system into which Document Instance content regions are placed and optionally clipped.

8.2.14 tts:origin
The tts:origin attribute is used to specify the x and y coordinates of the origin of a region area with respect to the origin of the Root Container Region.

It seems clear to me: tts:origin of (0% 0%) is the upper left of the visible area of the display, not the upper left of the safe title area. It’s similarly clear that ttml1 doesn’t describe constraints with respect to the safe area on where within the Root Container Region regions may be positioned.

Additionally, imsc1.0.1 explicitly requires (in most cases) "the Root Container Region of a Document Instance SHALL be mapped to the image frame in its entirety."

[palemieux]

However, I can't find that as a requirement (or even a recommendation) for 608/708 conversions anywhere.

@adam-gol Please see SMPTE RP 2052-10, 5.8.2.

IThere's a suggestion that perhaps IMF makes this requirement/recommendation. I don't think it does.

As far as I know:

• IMF specifies that the root container region is mapped to the production aperture (Display rectangle in MXF terminology).
• IMF does not currently recommend a safe area. This is left to delivery specifications. [ed.: I have seen safe area requirements in delivery specifications.]

start-brainstorming
IMF could recommend a safe area if such a recommendation made sense worldwide.

IMF could also recommend that ittp:activeArea be set to the safe area.

This would best discussed within SMPTE and/or the IMF UG.
end-brainstorming

[adam-gol]

Thanks, @palemieux, I hadn't considered RP 2052-10. Of course, it only describes the mechanisms for converting from 608/708 to ttml, so there remains no text (that I can find so far) that constrains ttml content (for television) to within the safe title area.

I think we're likely to end up addressing this in ATSC, but perhaps there is an opportunity to address this world-wide somehow as well.

[palemieux]

Of course, it only describes the mechanisms for converting from 608/708 to ttml

Yes, it however addresses the common use case where most (television) captioning is initially authored in 608 and then converted.

that constrains ttml content (for television) to within the safe title area.

Doesn't SMPTE ST 2046-1 already specifies a safe area for captions?

[adam-gol]

Yes, it however addresses the common use case where most (television) captioning is initially authored in 608 and then converted.

Absolutely. Alas, it's only a RP.

that constrains ttml content (for television) to within the safe title area.

Doesn't SMPTE ST 2046-1 already specifies a safe area for captions?

Well, it does for all "significant title information", which probably includes captions (but that's not explicit). Furthermore, I'm not sure that a broadcast is required to conform to SMPTE ST 2046-1. These problems for ATSC can be solved within ATSC.

Thanks for your help, @palemieux .

[dkneeland]

@adam-gol

My recommendation is that we continue to keep things consistent between subtitle and CC best practices.

0% 0% = upper left of screen
100% 100% = bottom right of screen

My full frame content subs typically use tts:origin="5% 5%" tts:extent="90% 90%".

The placement of the event can go outside of safe title area if a creative chooses to do so, however typically subs will be authored so that they don't extend into 5% of any of the sides of the screen.

Are you trying to currently solve for differences in title safe between regions, or are you looking to make a cleaner XML document?

[adam-gol]

My recommendation is that we continue to keep things consistent between subtitle and CC best practices.

I'm trying to understand this. CC (608/708) doesn't permit rendering of captions outside of the safe title region (well, that is, it's explicit that 0,0 is the upper left of the safe title region), while it seems that imsc1 (0,0) is the upper left of the screen.

That is, it's inconsistent now, so how do we keep it consistent?

[palemieux]

That is, it's inconsistent now, so how do we keep it consistent?

SMPTE RP 2052-10 specifies how to map the 608/708 safe area to the root container region such that (0,0) in 608/708 coordinates correspond to (10%,10%) in IMSC coordinates -- assuming a 80% safe area.

Makes sense?

P.S.: There no conformance difference between a SMPTE ST and RP.

[dkneeland]

I'm trying to understand this. CC (608/708) doesn't permit rendering of captions outside of the safe title region (well, that is, it's explicit that 0,0 is the upper left of the safe title region), while it seems that imsc1 (0,0) is the upper left of the screen.

TTML is simply a way to store the CC information so that it can be transformed into CC data upon playback. It is not natively a CC file, but it must be authored in a way so that once it's converted into CC it is done correctly. To your point, if a user places an event outside of safe title, then that source is a non-compliant asset and should fail in a broadcast compliance checker. Other items would also have to be checked, such as characters per line, words per minute, spelling, etc.

That is, it's inconsistent now, so how do we keep it consistent?

In my experience, TTML CC files have always required that the user account for safe title area when authoring those documents.

[nigelmegitt]

Chair hat on
This is an important operational consideration, and it is important for folk writing converters, but I would agree that it is out of scope of the IMSC specification.

Chair hat off, BBC hat on
For information, we have a similar issue when converting Teletext / STL to IMSC (and if necessary, the other way). The Teletext spec does not state anywhere the positioning and sizing of the Teletext rendering area on the video; making things more complicated, it was obviously designed in a 4:3 era, and we now use 16:9.

I haven't managed to update the BBC's subtitle guidelines to reflect this yet, but I expect us to use the following algorithm for positioning the Teletext content in the 16:9 rendering area used to present our IMSC/EBU-TT-D subtitle documents:

• Top edge of line 1 is 5% down from the top of the area (NB no visible content is allowed on Teletext line 0)
• Bottom edge of line 23 is 5% up from the bottom of the area
• Horizontally, map to the central 75% of the area, but then also add to each side of that 0.5% to accommodate line padding without reducing the space available for rendering the text.

This would result in a calculated ittp:activeArea="12% 5% 76% 90%" for content that uses the furthest possible extents of the rendering area in the original Teletext. (side note: Teletext subtitles use the first 3 or 4 characters on the line for control codes to set background and foreground colour and the "box" mode - heuristics are needed to deduce the intended alignment, but we assume that, when left aligned, the intent for any character in the leftmost column is to push all the way to the left.)

@palemieux you brainstormed:

IMF could also recommend that ittp:activeArea be set to the safe area.

I'd strongly recommend against subverting the intent of activeArea: the idea is to indicate the actual used areas of the rendering area, not the maximum limits that were permitted during authoring.

Safe area?

The BBC's technical requirements for delivery define some safe areas for on screen text, i.e. burned into the video, not supplied as separate caption/subtitle files: they're all 90% of the height. Two widths are used, for different purposes: 67.5% and 90%.

[nigelmegitt]

@dkneeland you wrote:

TTML is simply a way to store the CC information so that it can be transformed into CC data upon playback. It is not natively a CC file, but it must be authored in a way so that once it's converted into CC it is done correctly.

I'm not sure how you're defining "CC file"? I definitely do consider our (BBC's) TTML files to be closed captions (we call them subtitles) files, and the ones we distribute are used as the input to our (non-broadcast) players to produce the subtitle presentation.

[adam-gol]

@dkneeland wrote:

In my experience, TTML CC files have always required that the user account for safe title area when authoring those documents.

And where is that required? [I believe we've gone 'round in a circle, this was my original question.]

If a converter complies with SMPTE ST 2052-10, then it is required. But otherwise, there's nothing in ttml1 or imsc1 that requires the safe area be clear of subtitles/captions.

Are you saying that SMPTE ST 2046-1's requirement re "significant title information" also applies to subtitles/captions? That would probably solve the problem, but neither ttml1 nor imsc1 makes that requirement, and it's also unclear to me whether "title information" includes captions/subtitles or not (it should, to be sure, but I don't know that it does).

Or are you saying there's some other requirement?

[nigelmegitt]

@adam-gol wrote:

But otherwise, there's nothing in ttml1 or imsc1 that requires the safe area be clear of subtitles/captions.

This is correct, and in my view, as it should be. In TTML (and by extension IMSC) there's a document processing context, the precise details of which are out of scope, and not defined. That would include details of the video, and the (spatial and temporal) alignment of the TTML presentation against such video. It's not even required that there is video! For example see IMSC §8.5 Related Video Object.

Every definition of safe area I'm aware of is there to provide some kind of protection against variability in the presentation of the video, for example due to overscan. If the related video is out of scope, then logically it follows that variability in the presentation of that related video is also out of scope.

If it's out of scope of IMSC and TTML, then that allows it to be defined by other referencing documents; however I don't think W3C can mandate which documents. Looking at the MAUR section on captioning, it certainly doesn't talk about such a safe area. Rather, it goes the other way and suggests that captions might be displayed outside the video area!

[adam-gol]

This is correct, and in my view, as it should be. In TTML (and by extension IMSC) there's a document processing context, the precise details of which are out of scope, and not defined.

Sorry, I was responding to @dkneeland's assertion "have always required."

And so, in conclusion, if there is to be a safe area requirement upon the TTML, it needs to be imposed by a document 'up the stack' (so to speak). Ok, thanks.

[dkneeland]

I'm not sure how you're defining "CC file"? I definitely do consider our (BBC's) TTML files to be closed captions (we call them subtitles) files, and the ones we distribute are used as the input to our (non-broadcast) players to produce the subtitle presentation.

Good point, I think my description was incomplete. What I was trying to say is that TTML is one text based format that is able to preserve the authored CC information, however it must go through final encode step in order for a consumer to view the CC data on their device. The point I was trying to make was that a user can include information within that TTML that would not be able to properly embed into the 608/708 payloads since it is out of compliance with those specs.

And so, in conclusion, if there is to be a safe area requirement upon the TTML, it needs to be imposed by a document 'up the stack' (so to speak). Ok, thanks.

Exactly.