-
Notifications
You must be signed in to change notification settings - Fork 10
Components
Nigel Megitt edited this page Nov 11, 2019
·
35 revisions
This page lists the components included in the interoperability kit, together with their Implementation requirements.
- These components were agreed in the group's face-to-face meeting in January 2016.
- Within each section (e.g. source, consumer), components are sorted in descending order of priority, as agreed at the meeting (column 'P' below).
- Components that members asked to exclude from the open-source project are not included.
- There is an implied structure of abstract base classes that are instantiated as concrete classes to make the software do something. This structure also allows different concrete classes to be mixed together to generate different behaviours: for example the simple consumer receives a sequence and outputs basic details about the text that would be displayed and the times, and that could be instantiated against a concrete implementation of a receiver for any carriage specification - the combination creates a tool that can validate the behaviour for EBU-TT Live sequences carried via a single mechanism
- Specifications for carriers will be written in parallel with the development of carrier components.
| P | Name | User story | Component | Comment |
|---|---|---|---|---|
| Source components | ||||
| 4 | As a developer/tester, I want a sequence of documents generated from text input so that I can develop/test an implementation against it. |
This component will output a sequence of EBU-TT Live documents from user input. The UI will include the following elements:
|
||
| 3 | As a developer/tester, I want an external reference clock so that I can ensure documents are processed correctly | Output a date-time value | UTC? | |
| 2 | As a broadcaster, I want to convert subtitles in teletext format to EBU-TT Live documents so that I can use legacy systems |
This component will take as its input teletext and output EBU-TT Live documents. The input can be one of:
|
||
| 2 | As a developer/tester, I want a sequence of EBU-TT Live documents generated automatically so that I can develop/test an implementation against it without the need to input text. | This component will take no input and provide no options. It will generate a sequence from a hard-coded text source (e.g. 'Lorem ipsum'). | ||
| 2 | As a playout service provider, I want to consume a cued EBU-TT Live sequence from an EBU-TT Part 1 document |
This component will take as it input:
|
TBC: cueing options. | |
| Processor components | ||||
| N/A | As a developer/tester, I want to consume 'noisy' sequences documents so that I can test my implementation against a known set of scenarios. |
This will take as its input a sequence of documents generated by a source component (see above), and will output the sequence with a pre-determined and documented set of complexities:
|
This was not discussed as a separate component in the F2F but for release planing it's better to create a simple version first. | |
| 4 | As a developer/tester, I want to control the level of 'noise' and complexity in a stream of EBU-TT documents so that I can test my implementation against different scenarios. | This will take as its input a sequence of documents generated by a source component (see above). It will expose methods for introducing complexity into the stream, for example: multiple sequences, overlapping timecodes, corrections, multiple styles. | TBC: what types of 'noise' to include, range/options for each and user input. Base this on experience with the Simple noise introducer. | |
| 3 | As a subtitle provider/broadcaster, I want to combine documents from alternating respeakers/stenographers into a single EBU-TT live stream | This component will implement Handover Management functionality to funnel sequences from 2 or more sources and combine them into a single EBU-TT Live sequence for sending downstream. | ||
| 3 | As a playout service provider, I want to add a delay to the emission of documents so that I can synchronise subtitles with audio. | This node will simply hold on to documents and release them at the end of the delay period in the same order that they arrived (FIFO). This node will not modify the documents in any way. The delay will be fixed. Negative delay values are not allowed. | ||
| 3 | As a playout service provider, I want to add a delay to the timings in documents so that I can delay the timings of subtitles. | This node modifies timings within the document. Implicitly timed documents are made explicit for non-zero delay values. Negative delay values are not allowed. | ||
| 3 | As a playout service provider, I want to add a variable delay to the emission of documents so that I can synchronise variable speed subtitles with audio. | This node will hold on to documents and release them at the end of the delay period in the same order that they arrived (FIFO). This node will not modify the documents in any way. The delay will be fixed. Negative delay values are not allowed. | TBC: logic for handling cueued documents when the delay decreses. | |
| 3 | As a playout service provider, I want to add a variable delay to the timings in documents so that I can delay the timings of subtitles by variable amount. | This node modifies timings within the document. Implicitly timed documents are made explicit for non-zero delay values. Negative delay values are not allowed. | ||
| 3 | As a playout service provider, I want to switch between multiple sequences so that I can choose which sequence is output. | This will be a source switching node. | ||
| 3 | As a playout service provider, I want to distribute a sequence so that it can be processed by multiple consumers. | This will be a distributor node. | Depending on carriage spec this may not be needed: for example the WebSocket protocol offers this natively since connections can be made from multiple destination nodes to the same source node. | |
| N/A | As a processor of EBU-TT Live documents, When I combine several documents, I want to merge identical styles and regions so that I output cleaner documents. | This is a helper component. Merging is based on declaration (attributes) not computation, i.e. if two styles/regions have different declarations that result in identical rendering they are not merged. See De-duplicator-scenarios. | ||
| N/A | As a processor of EBU-TT Live documents, When I receive a document which contains nested `div` or `span` elements, I want to flatten them so that I output documents that conform to the non-nesting requirements of EBU-TT-D (for example). | This is a helper component. Denesting attempts to preserve the computed styles of the output elements, as well as the ordering of content. Elements whose specified `region` attribute differs from that of an ancestor element are discarded. | ||
| Consumer components | ||||
| 6 | As a playout service provider, I want to convert EBU-TT-Live documents to EBU-TT-D documents so that I can distribute them to the end device. |
This component will:
|
||
| 5 | As a developer/tester I want a simple view of the text and times in a sequence of EBU-TT Live documents so that I can verify that they will be processed correctly. |
This component will be a simple receiver. It will provide the following functions:
|
||
| 4 | As a broadcaster/access services provider, I want to archive EBU-TT Live documents so that I can I can reuse and distribute them after live transmission as a single Part 1 document. | This is an archiver node. This component will assemble a sequence of EBU-TT-Live documents into a single EBU-TT part 1 document. It will extend the Simple Part 3 Consumer and be able to handle a 'noisy' source (e.g. missing documents, overlapping time codes) | ||
| Validator components | ||||
| 6 |
===== |
As a developer/playout service provider, I want to validate an EBUT-TT Live sequence against the specification so that I know if they conform to the specification |
This component will perform semantic validation of:
|
This becomes part of Simple part 3 consumer. The Simple consumer will configurable either to return text and times verbosely or to return validation results or both. |
| 2 | As a developer/playout service provider, I want to validate EBUT-TT Live documents so that I know if they are valid XML | This is a an XSD for validating a single EBU-TT part 3 document. | The validation against the XSD will be done in the Simple part 3 consumer. | |
| 1 | As a developer/playout service provider, I want to check that an EBU-TT Live document conforms to downstream requirements so that I know it will be successfully processed. | This component will validate a document against metadata instructions (e.g., if intended for Teletext, check that the document conforms to line length constraint). | ||
| Carriage components | ||||
| 4 | As a playout service provider, I want to carry EBU-TT Live documents over HD SDI so that I can pass EBU-TT Live around with video in a broadcast environment. | This adaptor will handle interfacing with SMPTE 292M | Requires special equipment. Cards are usually for either input/output or processing. A processing card will be required for insertion of subtitles into an SDI signal. | |
| 4 | As a playout service provider, I want to carry EBU-TT Live documents using the RTP protocol so that I can use in EBU-TT Live over IP networks. | This adaptor will handle interfacing with RFC 3550 | ||
| 3 | As a playout service provider, I want to carry EBU-TT Live documents using the WebSocket protocol so that I can use in EBU-TT Live over TCP. | This adaptor will handle interfacing with RFC 6455 | ||
- Tests are required as part of the implementation to support test-driven development.
- Components must allow extension points.
- Use classes, not APIs. This is simpler to code and build even though it is ultimately less flexible.
- Provide abstract classes.
- Python will be used.
- Encoding and decoding code should be symmetrical/similar so one can be inferred from the other