OVERVIEW OF DFXP BASED SUBTITLES

Transcription

1 OVERVIEW OF DFXP BASED SUBTITLES This chapter defines a Subtitle elementary stream format, how it is stored in an ISO Base Media File as a Track, and how it is synchronized and rendered in combination with video. The term Subtitle in this document is used to mean text and graphics that are stored separately, but presented in synchronization with video and audio Tracks. Subtitles include text, bitmap, and drawn graphics, presented for various purposes including dialog language translation, content description, and closed captions for deaf and hard of hearing. Subtitles Tracks are defined with a new media type and media handler, comparable to audio and video media types and handlers. Subtitle Tracks use a similar method to store and access timed Samples of Subtitle streams that span durations on the Movie timeline and thus synchronize with other Tracks selected for presentation on that timeline. Subtitle Samples control the presentation of rendered text, graphics, and stored images during their Sample duration, analogous to the way an ISO file audio Sample contains a sync frame or access unit of audio samples and presentation information specific to each audio codec that control the decoding and presentation of the contained audio samples during the longer duration of the ISO file Sample. The elementary stream format specified for Subtitles is a derivation of the W3C Timed Text (TT)/Distribution Format Exchange Profile (DFXP) standard. Although the DFXP format was primarily designed for the presentation of character coded text using font sets, this document specifies how it can be used to also present bitmapped images stored in commonly used image media types. Both text and images have advantages for Subtitle storage and presentation, so it is useful to have one format to store and present both, and allow both in the same stream. Some Subtitle content originates in text form (such as most Western and European broadcast content), while other Subtitle content is created in bitmap format (such as DVD subpictures, Asian broadcast content, and some European broadcast content). Text has advantages such as: It requires very little size and bandwidth, is searchable, can be presented with different styles, sizes, and layouts for different displays and viewing conditions, and for different user preferences, and it can be converted to speech and tactile readouts (for visually impaired), etc. However, image subtitles allow authors to create their own glyphs (bitmapped images of characters), rather than use and license the relatively small number of characters used in a single presentation along with a potentially large and expensive font set, e.g. a CJK font set (Chinese, Japanese, Korean) may require 50,000 characters for each face vs. about 100 for a Latin alphabet. With bitmap images, an author can control and copyright character layout, size, overlay, painting style, and graphical elements that are often spontaneous and important stylistic properties of Asian writing; but with a loss

2 of storage efficiency and adaptation flexibility for the needs of a particular display and viewer as the result of the information being stored and decoded as a picture. By specifying a storage and presentation method that allows both forms of Subtitles, this Subtitle format allows authors and publishers to take advantage of either or both forms. A DFXP document, as defined by W3C, uses XML markup language similar to HTML to describe the layout and style of text, paragraphs, and graphic objects that are rendered on screen. Each text and graphics object has temporal attributes associated with it to control when it is presented and how its presentation style changes over time. In order to optimize streaming, progressive playback, and random access user navigation of video and subtitles, this specification defines how DFXP documents and associated image files must be organized and stored as multiple documents and files in an ISO Base Media Track. Images are stored separately as files and referenced from the DFXP documents in order to keep the size of each document small to enable fast parsing in limited player memory. 6.1 DFXP Document Stream Structure (Normative) A DFXP Document Stream SHALL consist of one or more DFXP compliant XML documents, each containing Subtitle presentation markup language restricted to a specific time span. A set of documents comprising a stream SHALL sequentially span an entire Track duration without presentation time overlaps or gaps. Initial documents (I-docs) SHALL contain DFXP information that is not directly displayed, such as Styles, Fonts, and structural elements. Subsequent Presentation documents (P-Docs) SHALL include text and/or referenced images that will actually be presented, and MAY include parts of the previous I-Doc using the include function. I-Docs MAY contain large or complex information, such as fonts and style sheets, which require significant processing time prior to the start of Subtitle presentation. I-DOCs SHALL NOT exceed a maximum size of 300 kilobytes. Track presentation timing SHALL allow ten seconds or more for an I-DOC to be processed, even though it has no intrinsic presentation duration. P-Docs SHALL NOT exceed a maximum size of 10 kilobytes to enable limited devices to parse and display information at the correct time. P-DOCs MAY include by reference larger and more complex pre-parsed components of the I-Doc they follow. P-DOCs MAY incorporate images in their presentation by reference. Both I-Docs and P-Docs SHALL be independently valid DFXP documents. More than one sequence consisting of an I-DOC followed by related P-DOCs MAY be stored sequentially in a Track, for instance to provide different fonts and styles to different video segments of a Track, e.g. previews, main feature, extra features, advertisements, etc.

3 Note: Each document is analogous to a video I-frame or P-frame in that P-Docs may reference an I-Doc, which must be acquired and processed before the P-Doc can be presented. Unlike video Samples, a single DFXP document may have a long presentation time during which it will animate glyphs and bitmap images over a large number of video frames as the DFXP renderer updates Subtitle images in response to the current value of the Track time base. Initial Document Head of file Setup Time Fonts, Styles, etc. Presentation Doc Text Image URIs Includes from I-Doc Presentation Doc Text Image URIs Includes from I-Doc Figure 6-1 DFXP Document Stream for Text Subtitles Table 6-1 An example of DFXP document files for a 60 minute text Subtitle Track Filename Description Asset1_DFXP_EN_0.xml I-Doc File containing static header information that applies to the entire track and time interval between 0 and 10 seconds used for delivery and setup. Asset1_DFXP_EN_1.xml P-Doc file for the time interval between 10 seconds and 10 minutes. Contains a reference to the header data of file Asset1_DFXP_EN_0.xml. Asset1_DFXP_EN_2.xml P-Doc file for the time interval between 10 and 20 minutes. Contains a reference to the header data of file Asset1_DFXP_EN_0.xml. Asset1_DFXP_EN_6.xml P-Doc file for the time interval between 50 and 60 minutes. Contains a reference to the header data of file Asset1_DFXP_EN_0.xml. 6.2 Subtitle Storage in an ISO Base Media File In an ISO Base Media File, each I-Doc SHALL be stored as a Sample. Each P-Doc and any images it references SHALL be stored as a Sample. Only one Subtitle Sample

4 SHALL be contained in one Subtitle Track Fragment that SHALL contain the data referenced by the Subtitle Sample in an MDAT Box. Images referenced by a P-DOC SHALL be stored in presentation sequence following the P-DOC that references them; in the same Subtitle Sample, data stream, and MDAT Box. Figure 6-2 Storage of Images following the related Presentation Document in an ISO Base Media Sample One Sample in one mdat Box in one Subtitle Track Fragment in one Move Fragment 6.3 Image storage Images SHALL be stored contiguously following P-DOCs that reference those images and SHOULD be stored in the same physical sequence as their time sequence of presentation. Image formats that contain separate components, such as color lookup tables and indexed images, SHOULD store those components in the sequence required for decoding. Note: Sequential storage of Subtitle information within a Sample may not be significant for random access systems, but is intended to optimize Tracks for streaming delivery. The total size of image data stored in a Sample SHALL NOT exceed 500 kilobytes. Image data SHALL include all data in the Sample except for the P-DOC, which SHALL be stored at the beginning of each Sample to control the presentation of any images in that Sample. When images are stored in a Sample, the Track Fragment Box containing that Sample SHALL also contain a Sub-Sample Information Box ( subs ). Each displayable image SHALL be defined as a Sub-Sample, and associated sequentially with the parameter subsample_count and subsample size in the subs Box. References to images in the Sample from a P-DOC SHALL use the integer value of subsample_count. 6.4 Subtitle Sample Constraints Subtitle Samples SHALL not exceed the following constraints: I-DOC size P-DOC size Subtitle Sample size, including images P-DOC Complexity Total XML document size <=200 kbytes Total XML document size <=10 kbytes Total Sample size <= 500 kbytes Ten display regions or less, 5k displayed characters or less per P-DOC

5 6.5 Hypothetical Decoder Model The hypothetical decoder model for Subtitles includes separate input buffers from the file parser for one I-DOC, one P-DOC, and a set of images contained in one Sample. Each buffer has a minimum size determined by the maximum document and Sample size. Additional buffers are assumed to contained infosets produced by parsing I-DOCs and P-DOCs to form functional object model representations in memory. Two P-DOC infoset buffers are assumed in order to allow the DFXP renderer to process a currently presenting infoset while a second P-DOC infoset is being created from a P-DOC delivered to the P-DOC buffer in preparation for presentation as soon as the times span of the currently active infoset is completed. Infoset buffers do not have a specified size because the amount of memory required to store compiled I-DOC and P-DOC infosets depends on how much memory an implementation uses to represents them. An implementation can determine a sufficient size based on document size limits and worst case code complexity. The I-DOC infoset remains in its buffer until another I-DOC has been read, and all P- DOCs that reference it have completed presentation. Then the next I-DOC can be read from the I-DOC buffer and compiled into an I-DOC infoset, replacing any previous infoset. P-DOCs that follow an I-DOC may include elements of the I-DOC infoset at any time (indicated by a dotted bidirectional arrow in the Subtitle hypothetical decoder diagram). Relatively large I-DOCs that are less time critical to parse remain in the I- DOC infoset buffer to make shared elements such as fonts and styles randomly accessible to P-DOCs using the include function so that rapidly changing presentation content can be processed in relatively small P-DOCs while maintaining accurate presentation timing in limited player memory and processing resources. In this decoder model, no decoded image buffer is assumed. It is assumed that devices have a fast enough image decoder to decode images on demand as required for layout and composition by the DFXP renderer. Actual implementations might decode and store images in a decoded image buffer if they have more memory than decoding speed. That does not change the functionality of the model or the constraints it creates on content. The DFXP renderer is also assumed to include a font and line layout engine for text rendering that is either fast enough for realtime presentation or can buffer rendered text to make it available as needed.

6 File Pars er I-DOC Buffer P-DOC Buffer Enc Image Buffer I-DOC Infoset P-DOC Infoset 1 P-DOC Infoset 2 Image Decoder DFXP Render Subtitle Overlay Plane Video Plane Figure 6-3 Block Diagram of Hypothetical Subtitle Decoder Document Buffer Size 220 kbytes minimum for three document buffers (one I-DOC, two P-DOC) Encoded Image Buffer Size 500 kbytes. Sample size is limited to 500 kbytes, but a P-DOC can be arbitrarily small, so nearly the entire Subtitle Sample could be filled with image data. Infoset Buffer Sizes No specific limitations. The infoset buffer sizes are limited by the XML document size, but the size of the infoset buffer relative to document size depends on the specific implementation. It is up to the decoder implementation to ensure that sufficient memory is available for the 3 infosets. Renderer Complexity Limits Max number of regions active at the same time: <=10 Maximum number of characters displayed in all active regions: <=5K 6.6 ISO Base Media File Box Constraints and Parameters The following Boxs SHALL be used for storage of Subtitle Tracks in a DECE ISO Base Media File. Figure 6-4 High level Sequence of Boxes and Subtitle Samples stored in an ISO file Subtitle Track TRAK Track Box MDIA Media Box MINF Media Inf. MOOF Movie Frag. TRAF Track Frag MDAT Data Box Chunk of Subtitle Data I-Doc, or P-Doc and optional images

7 Figure 6-5 Logical Structure of Next Level of Box Detail for a Subtitle Sample stored in a Movie Fragment trak Track Required trax Track External Optional: Used to include a Subtitle Track stored in another file. Note: This Box is defined in the DECE Media Format Specification Container chapter to reference a Track Box and its contained metadata and media data stored in a different file. It is contained in a Track Box that is otherwise empty, although it will logically contain the contents of the referenced external Track Box when its containing file is accessible. This permits independent storage, delivery, and synchronized playback of a Subtitle Track by a primary file that includes a Track External reference matching the URI of a secondary file containing a compatible ISO Base Media Track.

8 6.6.3 tkhd Track Header Layer= -1 (in front of video plane) Alternate_group = an integer assigned to all Subtitles in this presentation to indicate that only one Subtitle Track SHALL be presented simultaneously Track header flags (track_enabled, track_in_movie, and track_in_preview) SHALL be set to 1 (flag field set to 7). Other template fields SHALL be set to their default values Width and height SHALL be set (using fixed point values) to the width and height values of the DFXP root container extent or a region specified on the body element, normalized to square pixel values if tt:pixelaspectratio is not equal to the value uuid - Track Encryption This Box SHALL only be present when a Subtitle Track is encrypted. It SHALL be used to set a default value for the following parameters. The default value may be overridden in each Track Fragment (which corresponds to a Subtitle Sample) using the Override TrackEncryptionBox flag and corresponding parameter in the Track Fragment s Sample Encryption Box. default_algorithmid SHALL be set to 0x2 for full Sample AES-128 CBC mode encryption. A Track may only use one non-zero AlgorightmID. Note that a value of 0x0 in a Sample Encryption Box with Override TrackEncryptionBox flag=1 indicates that the Track Fragment is not encrypted. default_iv_size SHALL be set to 16 bytes. KID (key identifier) SHALL be set to an integer value that identifies the key used to encrypt this Subtitle Track. Only one encryption key and KID SHALL be used per Track, if encryption is applied. Note: Content management systems can use the KID value stored here to identify the appropriate encrypted Track key protected, conveyed, and indexed by external means not defined in this specification. The encrypted Track key can then be decrypted in a secure environment and used to decrypt the encrypted Samples in this Track mdia Media Required container for Subtitle Track media information mdhd Media Header General information about the Track, such as language and duration. Not media type specific hdlr Handler Reference Declares the process by which media data in this Track is presented, and therefore the type of media in the Track. handler_type for a Subtitle Track defined in this specification SHALL be set to the 32 bit integer equivalent to the string subt.

9 name SHALL be set to the UTF-8 characters Subtitle, Caption, Description, or Other minf Media Information The Box contains objects that describe the media format of the Track sthd Subtitle Media Header This Box is defined in this specification to correspond to the Subtitle media handler type. It Shall be required in the minf Box of a Subtitle Track Syntax aligned(8) class SubtitleMediaHeaderBox extends FullBox ( sthd, version = 0, flags) { } Semantics version is an integer that specifies the version of this Box. flags is a 24-bit integer with flags (currently all zero) stbl Sample Table A container that holds Boxes that provide time and location indexing of the Subtitle Samples stored in this Track. The Sample Table Box SHALL contain the following Boxes: Sample Description, Sample Size, and Time to Sample. (Sample to Chunk, Chunk Offset?) stsd Sample Description This specification SHALL use a version 1 stsd Box extended to include Subtitles Syntax aligned(8) class SampleDescriptionBox (unsigned in(32) handler_type) extends FullBox ( stsd, version = 1, 0){ int i ; unsigned int(32) entry_count; for (I = 1 ; i<= entry_count ; i++){ switch (handler_type){ case soun : // for audio Tracks AudioSampleEntry(); break; case vide : // for video Tracks VisualSampleEntry(); break; case hint : // for Hint Tracks

10 HintSampleEntry(); break; case meta : // for Metadata Tracks MetadataSampleEntry(); break; case subt : //for Subtitle Tracks SubtitleSampleEntry(); Break; } } } class SubtitleSampleEntry() extends SampleEntry (codingname) { string content_encoding; // optional string namespace; string schema_location; // optional string image_mime_type; // required if Subtitle images present BitRateBox (); // optional } Semantics version SHALL be the integer value 1 indicated a version of the stsd Box that includes sample entries for Subtitle media type content_encoding and schema_location - allow for future application of Subtitle XML compression methods such as BiM. image_mime_type SHALL indicate the media type of any images present in Subtitle Samples, including in-line in DFXP documents. The string SHALL remain empty when images are not present in Subtitle Samples or documents. Only one image_mime_type or none is allowed for all the Samples in one Track stts Decoding Time to Sample Required sample_delta SHALL be equal to the presentation duration of a Subtitle P- DOC, and in the case of an I-DOC, SHALL be assigned a sufficiently large sample_delta (e.g. 10 seconds) to allow a reader to read and parse the I-DOC prior to a subsequent P-DOC. Decoding time SHALL be considered equal to the Start of a Subtitle Track Fragment and the Sample it contains, and duration spans to the next Track Fragment and Sample in that Subtitle Track stsz, stz2 Sample Size Required. Only one of the two variants SHALL be used.

11 stsc Sample to Chunk Required. This Box is retained for compatibility, but is somewhat redundant since each Subtitle Sample is stored as a single Chunk stco, co64 Chunk Offset Required. The byte offset from the start of the ISO file to the start of a Subtitle Sample, which is stored as a single Chunk subs Sub-Sample Information Box SHALL be required for Subtitle Samples containing images that are not embedded in a document. When a subs Box is required, it SHALL be stored in the traf Track Fragment Box that contains the Subtitle Sample Semantics Applied to Subtitles subsample_count is an integer that specifies the number of sub-samples for the current Subtitle Sample. It SHALL equal 1 plus the number of images stored in the Subtitle Sample. Each image format used for Subtitles SHALL have a consistent definition of what constitutes an image and sub-sample so that DFXP documents can reference images stored in the Subtitle Sample by their index number. Image formats that include data structures other than images (e.g. colour lookup tables) SHALL define whether those are indexed as individual sub-samples, or combined with adjacent images as a single sub-sample. subsample_size is an integer equal to the size in bytes of the current subsample table entry ctts Composition Time to Sample SHALL NOT be included. Note: Composition timing is controlled by Subtitle P-DOCs over their entire duration, and a single P-DOC could have a duration equal to the entire Track mvex Movie Extends Required for DECE files. Indicates the presence of movie Fragments in the file mehd Movie Extends Header Box Required for DECE files. Provides the overall duration of a Movie consisting of movie Fragments. The Movie duration is equal to the duration of its longest Track; in this case a sequence of Track Fragments. When the duration is unknown, such as the case of live streaming, the Box may be omitted.

12 moof Movie Fragment Required. A top level Box, at the same logical level as the moov Box. It contains a Movie Fragment Header Box and a single Track Fragment Box; in this case a single Subtitle Track Fragment containing a single Subtitle Sample. In the DECE specification, Movie Fragments are stored in a sequence corresponding to the presentation times of their Track Fragments mfhd Movie Fragment Header Required. sequence_number is a positive integer that SHALL start at 1 and sequentially index Movie Fragments in their stored order trex Track Extends Required. One for each Track, stored in the mvex Box. Contains default parameters applied to all Track Fragments in a Track (unless overridden by a Fragment) traf Track Fragment Required for DECE files, and one only stored in each moof Box tfhd Track Fragment Header Required. One only stored in each traf Box. Sets default parameters, which will be applied to Subtitle Track Fragments since defaults will only apply to a single Sample and trun. No tf_flags SHALL be set trun Track Fragment Run Required for a Subtitle Track Fragment containing a Subtitle Sample, in which case one only trun SHALL be stored in the traf Box. Since only one Subtitle Sample SHALL be present, the sample_size and sample_duration parameters SHALL be included and corresponding flags set. (sample_size_present, and sample_duration_present). Other flags are not set sdtp Independent and Disposable Samples tfra Track Fragment Random Access Required for DECE files. One only stored in the mfra Movie Fragment Random Access Box. tfra provides a table to each random access point in a Track. 6.7 DFXP Document format Subtitle I-DOCs and P-DOCs SHALL conform to the Presentation Profile of DFXP [DFXP], and additional constraints specified in this Subtitle specification, including Timed Text extensions specified by SMPTE [SMPTE-TT].

13 The term root fragment in Appendix M of the DFXP SHALL be equivalent to the term I-DOC in this Subtitle specification. Subtitle documents SHALL optionally reference other Subtitle documents in an ISO Base Media Track using a positive integer starting with the number 1 for the first I- DOC in the Track, which also corresponds to the Track Fragment Number and Movie Fragment sequence number (traf_number paramter in the tfra Track Fragment Random Access Box and sequence_number in the mfhd Movie Fragment Header Box). Note: Document file names are not retained in the ISO file, but Movie Fragment Headers and the Track Fragment Random Access Box provide both sequential and random access indexes to documents, Samples, and Fragments of Subtitle Tracks G.2 DFXP Presentation Profile The DFXP Presentation Profile is intended to be used to express minimum compliance for presentation processing. <?xml version="1.0" encoding="utf-8"?> <!-- this file defines the "dfxp-presentation" profile of ttaf1-dfxp --> <profile xmlns=" <features xml:base=" <!-- required (mandatory) feature support --> <feature value="required">#content</feature> <feature value="required">#core</feature> <feature value="required">#presentation</feature> <feature value="required">#profile</feature> <feature value="required">#structure</feature> <feature value="required">#time-offset</feature> <feature value="required">#timing</feature> <!-- optional (voluntary) feature support --> <feature value="optional">#animation</feature> <feature value="optional">#backgroundcolor-block</feature> <feature value="optional">#backgroundcolor-inline</feature> <feature value="optional">#backgroundcolor-region</feature> <feature value="optional">#backgroundcolor</feature> <feature value="optional">#bidi</feature> <feature value="optional">#cellresolution</feature> <feature value="optional">#clockmode-gps</feature> <feature value="optional">#clockmode-local</feature> <feature value="optional">#clockmode-utc</feature> <feature value="optional">#clockmode</feature> <feature value="optional">#color</feature> <feature value="optional">#direction</feature> <feature value="optional">#display-block</feature> <feature value="optional">#display-inline</feature> <feature value="optional">#display-region</feature> <feature value="optional">#display</feature> <feature value="optional">#displayalign</feature> <feature value="optional">#dropmode-dropntsc</feature> <feature value="optional">#dropmode-droppal</feature> <feature value="optional">#dropmode-nondrop</feature> <feature value="optional">#dropmode</feature> <feature value="optional">#dynamicflow-character</feature> <feature value="optional">#dynamicflow-clear</feature> <feature value="optional">#dynamicflow-fill</feature> <feature value="optional">#dynamicflow-glyph</feature>

14 <feature value="optional">#dynamicflow-in</feature> <feature value="optional">#dynamicflow-jump</feature> <feature value="optional">#dynamicflow-line</feature> <feature value="optional">#dynamicflow-out</feature> <feature value="optional">#dynamicflow-rollup</feature> <feature value="optional">#dynamicflow-smooth</feature> <feature value="optional">#dynamicflow-teletext</feature> <feature value="optional">#dynamicflow-word</feature> <feature value="optional">#dynamicflow</feature> <feature value="optional">#extent-region</feature> <feature value="optional">#extent-root</feature> <feature value="optional">#extent</feature> <feature value="optional">#fontfamily-generic</feature> <feature value="optional">#fontfamily-non-generic</feature> <feature value="optional">#fontfamily</feature> <feature value="optional">#fontsize-anamorphic</feature> <feature value="optional">#fontsize-isomorphic</feature> <feature value="optional">#fontsize</feature> <feature value="optional">#fontstyle-italic</feature> <feature value="optional">#fontstyle-oblique</feature> <feature value="optional">#fontstyle-reverseoblique</feature> <feature value="optional">#fontstyle</feature> <feature value="optional">#fontweight-bold</feature> <feature value="optional">#fontweight</feature> <feature value="optional">#framerate</feature> <feature value="optional">#frameratemultiplier</feature> <feature value="optional">#layout</feature> <feature value="optional">#length-cell</feature> <feature value="optional">#length-em</feature> <feature value="optional">#length-negative</feature> <feature value="optional">#length-percentage</feature> <feature value="optional">#length-pixel</feature> <feature value="optional">#length-positive</feature> <feature value="optional">#length-real</feature> <feature value="optional">#length</feature> <feature value="optional">#linebreak-uax14</feature> <feature value="optional">#lineheight</feature> <feature value="optional">#markermode-continuous</feature> <feature value="optional">#markermode-discontinuous</feature> <feature value="optional">#markermode</feature> <feature value="optional">#metadata-foreign</feature> <feature value="optional">#metadata</feature> <feature value="optional">#nested-div</feature> <feature value="optional">#nested-span</feature> <feature value="optional">#opacity</feature> <feature value="optional">#origin</feature> <feature value="optional">#overflow-scroll</feature> <feature value="optional">#overflow-visible</feature> <feature value="optional">#overflow</feature> <feature value="optional">#padding-1</feature> <feature value="optional">#padding-2</feature> <feature value="optional">#padding-3</feature> <feature value="optional">#padding-4</feature> <feature value="optional">#padding</feature> <feature value="optional">#pixelaspectratio</feature> <feature value="optional">#rollup</feature> <feature value="optional">#showbackground</feature>

15 <feature value="optional">#styling-chained</feature> <feature value="optional">#styling-inheritance-content</feature> <feature value="optional">#styling-inheritance-region</feature> <feature value="optional">#styling-inline</feature> <feature value="optional">#styling-nested</feature> <feature value="optional">#styling-referential</feature> <feature value="optional">#styling</feature> <feature value="optional">#subframerate</feature> <feature value="optional">#textalign-absolute</feature> <feature value="optional">#textalign-relative</feature> <feature value="optional">#textalign</feature> <feature value="optional">#textdecoration-over</feature> <feature value="optional">#textdecoration-through</feature> <feature value="optional">#textdecoration-under</feature> <feature value="optional">#textdecoration</feature> <feature value="optional">#textoutline-blurred</feature> <feature value="optional">#textoutline-unblurred</feature> <feature value="optional">#textoutline</feature> <feature value="optional">#tickrate</feature> <feature value="optional">#time-clock-with-frames</feature> <feature value="optional">#time-clock</feature> <feature value="optional">#time-offset-with-frames</feature> <feature value="optional">#time-offset-with-ticks</feature> <feature value="optional">#timebase-clock</feature> <feature value="optional">#timebase-media</feature> <feature value="optional">#timebase-smpte</feature> <feature value="optional">#timecontainer</feature> <feature value="optional">#transformation</feature> <feature value="optional">#unicodebidi</feature> <feature value="optional">#visibility-block</feature> <feature value="optional">#visibility-inline</feature> <feature value="optional">#visibility-region</feature> <feature value="optional">#visibility</feature> <feature value="optional">#wrapoption</feature> <feature value="optional">#writingmode-horizontal-lr</feature> <feature value="optional">#writingmode-horizontal-rl</feature> <feature value="optional">#writingmode-horizontal</feature> <feature value="optional">#writingmode-vertical</feature> <feature value="optional">#writingmode</feature> <feature value="optional">#zindex</feature> </features> <extensions xml:base=" <!-- required (mandatory) extension support --> <!-- optional (voluntary) extension support --> </extensions> </profile> Carriage of Binary Data Binary data is carried in Subtitles using a DFXP Metadata element and the smpte:data element in the following manner: Example: Metadata encoding of binary data <metadata>

16 <smpte:data encoding= BASE64 datatype= type > encoded binary data here. </smpte:data > </metadata> If the datatype is not one of the data types defined by this standard, then it shall have a prefix x- to indicate a private data tunneling; any other data type is reserved by SMPTE for future standardization. Example: Proprietary Datatype <metadata> <smpte:data encoding= BASE64 datatype= x-privatetexttype > encoded data here. </smpte:data > </metadata> 6.8 Pre-rendered backgrounds Some legacy formats (for example DVB Subtitles and DVD subpictures) encode caption data as image data. While tunneling of the binary image data in the XML document is possible, a hybrid approach is desirable where the image data is presented by the DFXP document by reference, rather than binary embedding in the document. DFXP restricts the background rectangle of a rendered area to be single colors, for the purposes of SMPTE-TT the smpte:background-image attribute is defined for the <div> element. This reference should resolve to an image of the pre-rendered content of that area smpte:backgroundimage The smpte:backgroundimage attribute is used to specify a style property that defines the background image of an area generated by content flowed into a region. This attribute may be specified by any element type that permits use of attributes in the TT Style Namespace; however, this attribute applies as a style property only to those element types indicated in the following table. Values: Initial: Applies to: Inherited: Percentages: Animatable: <uri-specification> none none div no N/A none The tts:backgroundimage style is illustrated by the following example.

17 Example Fragment Background Color <region xml:id="r1"> <style tts:extent="306px 114px"/> <style tts:backgroundcolor="red"/> <style tts:color="white"/> <style tts:displayalign="after"/> <style tts:padding="3px 40px"/> </region>... <div region="r1" tts:backgroundimage="#image1" tts:color="transparent"><p> Twinkle, twinkle, little bat!<br/> How <span tts:backgroundcolor="green">i wonder</span> where you're at! </p> </div> Example Rendition Background Image [[picture here]] Note: The semantics of the style property represented by this attribute are based upon that defined by [XSL 1.1], Supported image types For DECE Subtitle Tracks, the URI reference is to an image stored as a numbered subsample in the same Sample as the P-DOC. The MIME type of the smpte:image element is determined by the MIME type stored in the Sub-sample table in the subs Box of the Subtitle Track. The following image formats are required to be supported by a conforming presentation processor: Format Code Reference Run length encoded DVB_RLE DVB Subtitle reference DVD subpicture DVD DVD Subpicture reference Graphics Image Format GIF GIF reference Rendering The referenced image is rendered in accordance with the XSL background-image trait [XSL 1.1 Section 7.8.3]. The foreground color for additional marks should be set to transparent. Presentation processors may, but are not required to render foreground marks over a background-image.

18 The background-repeat property is constrained to be no-repeat, and backgroundposition-horizontal and background-position-vertical are constrained to be center. The presented image is not scaled, and the XSL background-color trait will be visible for any background areas of the <div> outside the image, therefore authors should ensure that the div will be sized to match the given pre-rendering. 6.9 Font resolution DFXP specifies fonts by named strings. SMPTE-TT does not define specific fonts or font embedding semantics, however any system delivering SMPTE-TT must define a mechanism for mapping from <fontfamily> and <genericfontfamily> strings in a SMPTE-TT document to a set of known or delivered font resources SMPTE Metadata XML Vocabulary smpte:data The data element is used to record binary data of the input format used to generate the SMPTE-TT document. The data element accepts as a content model a text string which is the encoded binary data in the encoding format indicated by the encoding attribute XML Representation Element Information Item: date <data encoding = (BASE64) > datatype = (SMPTE_334_2 DVB_WST DVB_SUBTITLE EBU_SUBTITLE xml:id = ID Content: PCDATA </data> Only a single smpte:data element shall be present in a conforming SMPTE-TT document, and this shall be a child element of a DFXP <head> element. The presentation semantics of this element are defined as the reconstitution of the legacy format for use in a CE device that cannot display DFXP timed text. No other presentation semantics are defined for this data. Transformation engines shall preserve this data if and only if the transformation that they perform preserves the presentation semantics of the document; otherwise the transformation should remove this element smpte:image The image element is used to record a pre-rendered image (e.g. for DVD sub-picture). This may be referenced by the smpte:backgroundimage style attribute

19 XML Representation Element Information Item: image <image encoding = (BASE64) imagetype = (DVB_RLE DVD PNG) xml:id = ID > Content: PCDATA </data> Each smpte:image element present in a conforming SMPTE-TT document, shall be a child element of a DFXP <metadata> element. The presentation semantics of this element are defined by the backgroundimage style attribute smpte:information The information element to records details about the conversion process, including the type of data the document was translated from XML Representation Element Information Item: information <information origin = (<URI> CEA608 CEA708 DVB_WST DVB_SUBTITLE EBU_SUBTITLE NONE) threshold = <real> > xml:id = ID Content: EMPTY </data> Only a single smpte:information element shall be present in a conforming SMPTE-TT document, and this shall be a child element of a DFXP <head> element. No presentation semantics of this element are defined. Transformation engines shall preserve this data if and only if the transformation that they perform preserves the presentation semantics of the document; otherwise the transformation should remove this element. The origin attribute specifies the source format for the translation, the default value is NONE. The NONE value shall only be used for this attribute if the file was not translated

20 from any prior data (e.g. if it is generated from an authoring tool), otherwise a specific value must be used. A proprietary value is any fully qualified URI, indicating transformation of a format not defined by this specification. The threshold attribute value is a real number indicating a duration in fractions of a second; this documents the threshold time that was used during the conversion to suppress the conversion of temporary caption states. (default is 1/20 th of a second) 6.11 DFXP Subtitle Examples: The following example shows the contents of a document 0 which contains metadata and subtitling information for the time interval from 0s to 30s. Note, that there is no paragraph active from 15s to 30s even though this time interval is still covered by this document. This is a valid way of specifying that no text is displayed for this time interval. <?xml version="1.0" encoding="utf-8"?> <tt xmlns:xi=" xmlns=" xmlns:tt=" xmlns:ttm=" xmlns:tts=" xml:lang="en" xmlns:xsi=" xsi:schemalocation=" C:\Users\edwinsal\projects\SmoothStreaming\XML\StandardSchema\ttaf1-dfxp.xsd"> <head xml:id="base_header"> <ttm:title>example-000</ttm:title> <ttm:desc>example Test: 000; Duration: 4s; Test: Test specification example.; </ttm:desc> <ttm:copyright>copyright (C) 2008 W3C (MIT, ERCIM, Keio).</ttm:copyright> <styling xmlns:tts=" <!-- s1 specifies default color, font, and text alignment --> <style xml:id="s1" tts:color="white" tts:fontfamily="proportionalsansserif" tts:fontsize="22px" tts:textalign="center"/> <!-- alternative using yellow text but otherwise the same as style s1 --> <style xml:id="s2" style="s1" tts:color="yellow"/> <!-- a style based on s1 but justified to the right --> <style xml:id="s1right" style="s1" tts:textalign="end"/> <!-- a style based on s2 but justified to the left --> <style xml:id="s2left" style="s2" tts:textalign="start"/> </styling> <layout xmlns:tts=" <region xml:id="subtitlearea" style="s1" tts:extent="560px 62px" tts:padding="5px 3px" tts:backgroundcolor="black" tts:displayalign="after"/> </layout> </head> <body> <div> <p begin="0s" end="15s">test 1 2 3</p> </div> </body> </tt> The following example shows the contents of a document 1, which refers back to the metadata in document 0 and contains its own data for the time interval from 30s to 60s. <?xml version="1.0" encoding="utf-8"?> <tt xmlns:xi=" xmlns=" xml:lang="en" xmlns:xsi=" xsi:schemalocation=" schema\ttaf1- dfxp.xsd"> <xi:include href="chunk0.xml" xpointer="base_header"/> <body> <div> <p begin="30s" end="60s">test 4 5 6</p> </div> </body>

21 </tt> Changes to styles and layout, which apply only to a particular document, are best described using animations and the set element. However, it may be useful in some cases to be able to extend or modify the header for the scope of a document. This is possible by redefining the header, where necessary referencing header information from the metadata in order to reduce the overall data size. Document 2 below shows how this is done. <?xml version="1.0" encoding="utf-8"?> <tt xmlns:xi=" xmlns=" xml:lang="en" xmlns:xsi=" xsi:schemalocation=" schema\ttaf1- dfxp.xsd"> <!-- define a header as we cannot reuse an existing header as is--> <head> <styling xmlns:tts=" <!-- reuse a style that was defined in common header definition, refer to chunk 0 --> <xi:include href="chunk0.xml" xpointer="s1"/> <!--specify a style just for this document --> <style xml:id="temp_s" tts:color="black" tts:fontfamily="proportionalsansserif" tts:fontsize="20px" tts:textalign="right"/> </styling> <layout xmlns:tts=" <!-- reuse region that was defined in common header definition, refer to chunk 0. Uses style s1 --> <xi:include href="chunk0.xml" xpointer="subtitlearea"/> <!-- define a new region just for this document --> <region xml:id="tempsubtitlearea" style="temp_s" tts:extent="300px 5px" tts:padding="15px 13px" tts:backgroundcolor="green"/> </layout> </head> </tt> <body> </body> <div region="tempsubtitlearea"> <p xml:id="subtitle1" begin="60s" end="70s"> This is text in a temporary region </p> </div> <div region="subtitlearea"> <p xml:id="subtitle2" begin="70s" end="80s"> It seems a paradox, does it not, </p> <p xml:id="subtitle3" begin="80s" end="90s"> that the image formed on<br/> the Retina should be inverted? </p> </div>

22 Presentation Transitions between P-DOCs A DFXP document contains all information necessary to render the subtitling representation for the time interval covered by the document. This means, that it does not rely on state information contained in a previous document. The decoder must be able to start decoding a document by switching to a new infoset. In a typical case, this means that P-DOCs can start a new document at a point where no data is displayed on the screen. However, a document can also repeat information in order to make a seamless transition between two P-DOCs. For example, two documents could split a paragraph into consecutive paragraphs containing the same active text ending one document and starting the other. The second P-DOC continues the presentation to produce the same presentation as a single longer document. Example: The following paragraph would be broken into two time spans: <body region="subtitlearea"> <div> <p xml:id="subtitle1" begin="0s" end="300s"> Copyright 2008, don t copy </p> </div> </body> The result would look like this: Document 1, covering the interval 0 to 60 seconds: <body region="subtitlearea"> <div> <p xml:id="subtitle1" begin="0s" end="60s"> Copyright 2008, don t copy </p> </div> </body> Document 2, covering the interval 60 to 300 seconds: <body region="subtitlearea"> <div> <p xml:id="subtitle1" begin="60s" end="300s"> Copyright 2008, don t copy </p> </div> </body>

23 The DFXP standard specifies that the time interval includes the start time but not the end time. Therefore, these 2 paragraphs still cover the entire original time interval and according to the specification, the decoder should produce identical results (i.e. no redrawing should take place between the files).