Documents

• A document is a single entity conformant to this specification.
• Documents defined by this specification are live documents in the set of TTML Live Documents.
• An implicitly timed document is a document that contains no timing information and is considered active as soon as it has become available. It may also express a maximum duration after which it shall be deactivated.
• An explicitly timed document is a document that contains timing information and whose activation time depends both on when it has become available and the timing information that it contains, resolved using its time base and a reference clock source.
• When presenting a sequence of documents, at each moment in time exactly zero or one document shall be active.
• If no document is active, or if a document with no content is active, no content shall be displayed.

• Two document instances are considered identical if the result of the fn:deep-equal function [[xpath-functions-30]] is true when both document instances are provided as operands.

  For valid serialised XML documents if a byte comparison of the two documents shows they are identical then deep-equal is expected also to return true, however there are cases where serialisations are not identical in a byte comparison but deep-equal correctly reports that they are identical, for example if XML comments have been added or attributes have been reordered.

Sequences

• A sequence is a set of related live documents, for example the documents that define the subtitles for a single programme.
• Sequences shall be considered distinct if they have had processing applied, even if the result of that processing is no change other than a known difference in quality, for example if the processing has checked the spelling of the text content.
• Every distinct sequence shall have a unique sequence identifier.
• A sequence of implicitly timed documents can be transformed, with knowledge of the documents’ associated availability times, into a sequence of explicitly timed documents or a single document with explicit timings.
• Every document shall be associated with exactly one sequence and shall contain a sequence identifier.
• Sequences do not have an explicit existence other than being the set of their constituent live documents; the sequence identifier shall be present within every document in order to make concrete the association with the document's sequence.

• Every document shall contain a sequence number. Sequence numbers shall increase with the passage of time for each new document that is made available. Sequence numbers are used to resolve temporal overlaps: see . In case a document is received with the same sequence identifier and sequence number as a previously received document the later received document shall be discarded from processing.

  If sequence numbers begin at 1 then, at an example nominal mean rate of 1 document per second the maximum sequence number that will fit within a 4 byte unsigned integer corresponds to a sequence duration of over 136 years. Nevertheless sequences should begin at low sequence numbers such as 1 to avoid the possibility of an unwanted integer overflow.

• Every document in a sequence is by definition a valid and self contained document conforming to this specification.

  In general no knowledge of other documents is required to process it.

  Some specific kinds of processor may constitute exceptions, such as one that accumulates multiple documents together and combines them into a single one.

  For the purposes of efficiency, a processing node may store the preceding document for document comparison, e.g. when a subsequent document only changes the temporal validity of the document content.

• Sequences may be stored: that is, the lifetime of the sequence is unbounded.

Every document in a sequence shall have the same timing model as defined by using the same set of specified or absent values for the ttp:timeBase and ttp:clockMode attributes.

Nodes and streams

• A node is a TTML Live aware unit or mechanism that creates, emits, receives or processes one or more sequences.

• Nodes are identified.

  The format of node identifiers is not defined here.

• A node may offer a logical stream as the transfer of a sequence to one or more nodes. A logical stream is identified by the source node’s node identifier and the sequence identifier.
• A physical stream is the transfer of a sequence between two nodes. It is identified by the pair of node identifiers of the source node and the destination node and by the sequence identifier.

• Any number of nodes may process or consume the same logical stream: by definition the delivery of those streams requires one physical stream per destination node.

  A node can provide multiple physical streams of the same sequence.

• A processing node emits sequence(s) that are distinct from any of its input sequence(s). A creation node is a specialised processing node with zero input sequences.

  There can be little or no observable difference in content but the processing node has the potential to modify the output stream; for example a spell checker or profanity removal node might not make any changes most of the time but be called into action on an occasional basis. Nevertheless the output is considered to be different from the input because it has a logically different state, for example if it is known not to contain any profanities, and it is required to have a different sequence identifier.

• A passive node shall not modify input sequences and shall only emit sequences that are identical (including the sequence numbers) to the input sequence(s), for example nodes that are simply used for switching. A consumer node is a specialised passive node that does not emit any sequence.

  The outputs of a consumer node that is an encoder are not TTML Live documents.

• Streams are transient: that is, the lifetime of a stream is bounded by the period between the start of transfer (when the first document is transferred) and the end of transfer (when the last document is transferred). Streams may begin before the last document in the sequence has been generated - indeed it is envisaged that in normal operation documents within a sequence are generated dynamically and transferred in a stream with an undefined end time.

• The flow of a stream is unidirectional. Any ‘back channel’ reverse communication is external to the payload of the sequence.

  Nodes can subscribe to multiple streams; see the Handover Manager node at for example.

• At any moment in the presentation of a sequence by a node exactly zero or one document in that sequence shall be temporally active.

  The logic defining which document is temporally active is defined in .

Nodes are defined as abstract classes. Further detail of node behaviour is defined in . See also .

For correct temporal processing of streams, nodes are expected to maintain synchronisation between internal clocks used to compare documents’ availability times with the computed times for the documents’ contents.

The use of SMPTE time base is prohibited. This is because the combination of ttp:timeBase="smpte" and ttp:markerMode="discontinuous" implies that time expressions are merely markers that cannot be relied upon to increase monotonically. Therefore they are unsuitable for direct comparison purposes, which is a processing requirement for identifying temporal overlaps between documents. In practice any source of SMPTE timecode, for example timecode associated with video frames, even if intended to be continuous, can be subject to discontinuities for example at programme boundaries. Techniques for working around the absence of SMPTE time base are described in .

shows a UML class model illustrating the logical entities in this system model.

It is envisaged that some processing nodes will be purely software whereas others require human intervention.

Sequence identifiers should not be used as service identifiers, such as broadcast television channel identifiers. For example consider the case of a ‘simulcast’ where a single video source is broadcast on more than one output service simultaneously, perhaps to support localised services or both standard definition and high definition video services, with the same audio. A subtitler can only observe a single media source at any moment, and generates a single sequence with a single sequence identifier, which could be subsequently processed, generating new sequences with different identifiers. Those sequences could be destined to be encoded for multiple output or destination services. Destination service identifiers may be carried as metadata within documents. Similarly the observed source service identifier may be carried as metadata within documents.

Document resolved begin and end times

Every document in a sequence has a time period during which it is active within a presentation, defined in [[TTML1]] as the Root Temporal Extent. At any single moment in time during the presentation of a sequence either zero documents or one document shall be active. The period during which a document is active begins at the document resolved begin time and ends at the document resolved end time.

It is not necessary for all classes of processor to resolve the document begin and end times. For example a processing node that checks text spelling only can do so without reference to the timing constructs defined in this section.

Buffer Delay Node

The following behaviours of a Buffer Delay node are defined, in relation to the sequences that they receive and emit:

1. A Buffer Delay node is a passive node. Therefore the output documents shall be identical to the input documents.
2. A Buffer Delay node shall delay emission of the stream by a period not less than the offset period.
3. The offset period shall not be negative.

In the context of a buffer delay node a negative offset period would require documents to be emitted before they had arrived. No practical device has yet been demonstrated that can achieve this in the general case.

Retiming Delay Node

The following behaviours of a Retiming Delay node are defined in relation to the sequences that they receive, process and emit:

1. A Retiming Delay node is a processing node. Therefore the output sequence shall have a different sequence identifier from the input sequence.
2. A Retiming Delay node shall modify each document to result in the document’s computed times being increased by the offset period.

   In general this results in implicitly timed documents being converted to explicitly timed documents, since all but a zero offset period requires at a minimum a begin attribute on an element, for example the tt:body element. This behaviour may be surprising.

3. The offset period shall not be negative.
4. A Retiming Delay node should not emit an output sequence with reordered subtitles.
5. A Retiming Delay node shall not update the value of ebuttm:authoringDelay, if present.
6. A Retiming Delay node should add an ebuttm:appliedProcessing element to the document metadata to indicate that the delay has been added.

In the context of a retiming delay node, applying a negative offset period could result in documents having negative begin attribute values, which is not permitted in TTML.

It is possible that delay functionality is combined with other processing in a single node, for example an accumulator; hence the requirement not to reorder is expressed in terms of subtitles not documents: there is for example no requirement that there is a 1:1 relationship between input and output documents from a Retiming Delay node, though such a relationship would be expected for the simplest conceivable Retiming Delay.

If varying the delay offset period, take care to manage the other timings to avoid inadvertently changing the displayed order of subtitles; for example one strategy could be to treat delay offset period changes as target values that are arrived at over a fixed period, so instead of jumping from, say, 10s to 4s in one step an implementation could gradually reduce the offset from 10s to 4s over, say, a 6s period. Another strategy when the delay varies is to allow the node (or a downstream node) to apply its own logic, which could result in documents being skipped to achieve the desired synchronisation.

Authors Group parameters

The following parameters on the tt:tt element are provided to facilitate handover:

The ebuttp:authorsGroupIdentifier is a string that identifies the group of authors from which a particular Handover Manager can choose. A Handover Manager should be configured to subscribe to all the streams whose documents have the same ebuttp:authorsGroupIdentifier except for its own output stream. Within a single sequence, all documents that contain the element ebuttp:authorsGroupIdentifier shall have the same ebuttp:authorsGroupIdentifier.

The Handover Manager may include within each document in its output sequence the parameter attributes ebuttp:authorsGroupIdentifier and ebuttp:authorsGroupControlToken from the current selected sequence. The Handover Manager includes within each output document the metadata attribute ebuttm:authorsGroupSelectedSequenceIdentifier [[EBU-TT-M]] set to the value of the source sequence’s sequence identifier for that document. This is so that each subscriber to the Handover Manager's output stream can know the current status, including any subscribed subtitle authoring stations.

The Handover Manager’s normative behaviour is defined in .

When present in a document, the ebuttp:authorsGroupControlToken is a number that the Handover Manager uses to identify which sequence to select: when a document is received with a higher value ebuttp:authorsGroupControlToken than that most recently received in the current selected sequence the Handover Manager switches to that document's sequence, that is, it emits a document in its output sequence corresponding to and derived from the received document with the new control token without delay.

Having selected a sequence, the Handover Manager emits further documents derived from that sequence until a new sequence is selected.

This means that the control token value can be lowered after taking control, by setting the control token value in a new document in the selected sequence to a lower number. Therefore the control token value does not need to increase forever.

Regardless of the selected sequence, the Handover Manager does not emit any documents derived from input sequence documents that do not contain both the parameters ebuttp:authorsGroupIdentifier and ebuttp:authorsGroupControlToken.

Care should be taken if the carriage mechanism does not guarantee delivery of every document in the sequence in case a document intended to take control is lost. One strategy for avoiding this would be for the subtitle authoring station to observe the Handover Manager's output and verify that control has been taken before lowering the control token value. Another strategy would be to maintain the high control token value and duplicate it in each document in the sequence until the sequence switch has been verified through another mechanism.

Handover Manager algorithm

The Handover Manager node uses the following 'who claimed control most recently' algorithm for selecting the sequence, based on the control token parameter present within each document.

The Handover Manager shall maintain all of the following variables:

• a token T equal to the value of the ebuttp:authorsGroupControlToken of the most recently emitted document, or a null value if no document has been emitted;
• a record S_s of the sequence identifier of the source sequence used to generate the most recently emitted document, known as the selected sequence, initially a null value until a sequence is selected;
• a record AG of the configured authors group identifier;
• an output sequence identifier S_o.

When new incoming data is received, the Handover Manager shall:

1. If the input data is a valid document that contains all of: 1) a present and valid ebuttp:authorsGroupIdentifier equal to AG; and 2) a present and valid ebuttp:authorsGroupControlToken, then treat the document as the “input document” and execute the following sub steps in the stated order:
   1. If T is null (and therefore by definition S_s is also null), or if T is not null and the input document’s ebuttp:authorsGroupControlToken is greater than T, then select the input document’s sequence by executing the following sub-steps in any order:
      1. set T to the input document’s ebuttp:authorsGroupControlToken.
      2. set S_s to the input document’s sequence identifier.
   2. If and only if the input document’s sequence identifier equals S_s (that is, the input document is from the selected sequence), then execute the following sub steps in the stated order:
      1. generate an output document based on the input document, setting the output document’s sequence identifier to S_o and allocating a valid sequence number greater than the most recently emitted sequence number, and adding an ebuttm:authorsGroupSelectedSequenceIdentifier attribute set to S_s;
      2. emit the output document;
2. Otherwise do not emit a document.

Any implementation that provides the above algorithm’s outputs given any input documents satisfies the requirements; it is not required that implementations use code that exactly matches the steps.

This algorithm may be extended in implementations for example to set specific behaviour when basing an output document on the input document, or to define emission rules for other types of live document.

Generic Constraints

The TTML Live extensions define constraints for an XML document instance. A valid TTML Live document shall comply with the generic constraints in and the document structure defined in .

Document Structure and Content Profile

This section specifies constraints on document instances relative to [[TTML1]] and [[TTML2]], including prohibited and mandatory vocabulary.

TTML Live documents shall be valid TTML documents. [[TTML2]]

Definitions used within this section:

Rows highlighted in grey and marked as required or cardinality 1..1 indicate required attributes.

Supported Features and Extensions

Generic Node Classes

This section defines the behaviours of nodes. The nodes are specified as abstract classes that inherit behaviour from their parent. This section is structured according to the inheritance tree, so a subsection inherits the definitions of its parent section within the document. For example a Processing Node is a Node.