DECE subtitle proposals SPE

Transcription

1 DECE subtitle proposals SPE

2 Open Issues #8 Font Size #11Forced subtitle #13 Subtitle positioning New issues Clarification of timeline for timed text and Chapter mark Font pre-load buffer Proposals SMPTE TT filename extension

3 #8: Font size

4 Font size Status Current XSL Pixel definition is as follows Pixels XSL interprets a 'px' unit to be a request for the formatter to choose a device-dependent me asurement that approximates viewing one pixel on a typical computer monitor. This interpret ation is follows: The preferred definition of one 'px' is: The actual distance covered by the largest integer number of device dots (the size of a device dot is meas ured as the distance between dot centers) that spans a distance less-than-or-equal-to the distance specifie d by the arc-span rule in or superceding errata. A minimum of the size of 1 device dot should be used. This calculation is done separately in each axis, and may have a different value in each axis. 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").

5 Font size Proposal Need definition for <length> px (pixel) unit of measurement Should be the subtitle media(root container extent) s pixels and not dependen t on display device pixels Need clarification when non-square PAR is involved Regardless of font size, devices shall support 50chars/sec Device should be capable of displaying up to 72(or 144) pixel size fonts at 50c hars/sec (content size) fonts Should not allow devices that only support up to 12pixel size fonts and claim compliance. Players may enlarge font size further(e.g. larger than 144 pixel size), but shall not drop bel ow 50chars/sec performance

6 #11: Forced subtitle

7 Forced subtitle definition Forced: These are common on movies. Forced s ubtitles only provide subtitles when the character s speak a foreign or alien language, or a sign, fla g, or other text in a scene is not translated in the l ocalization and dubbing process. In some cases, foreign dialogue may be left untranslated if the m ovie is meant to be seen from the point of view of a particular character who doesn't speak the lang uage in question.

8 Forced subtitle Use case: translation of in-video signs etc. language credit etc.. Status TWG comment: metadata type attribute can be used, type=forced indicates forced subtitle This only applies to a track. When user has selected a subtitle track and temporarily disables it, when a forced sub is encountered the subtitle track will switch to a forced subtitle track. When the user enable s the subtitle, the track will no longer be the same track. Need mechanism to include forced subtitle events within a normal subtitle track

9 Forced subtitle Proposal: Define a new xml attribute force d Namespace: should be defined Value: boolean Initial: false Applies to: body, div, p, region, span

10 #13: Subtitle Positioning

11 Subtitle positioning Status Need clarification for subtitle positioning relative to video Proposal The width and the height fields of the Track Header Box shall be set to the corresponding dimension of the frame size of on e of the picture formats allowed for the current Media Profile. (see Annexes). All subtitle track header width and heights shall be the same value in a single CFF file No clipping: Regions should not extend beyond the boundaries of the root container

12 Root container extent definition W3C TTML tt If the tts:extent attribute is specified on the tt element, then it must adhere to tts:extent, in which case it s pecifies the spatial extent of the root container region in which content regions are located and presented. If no tts:extent attribute is specified, then the spatial extent of the root container region is considered to be determin ed by the external authoring or presentation context. The root container origin is determined by the external aut horing context. W3C TTML tts:extent The root container extent is determined either by a tts:extent specified on the tt element, if present, or by the ex ternal authoring context, if not present. If tts:extent is specified on the tt element, then the width and height mus t be expressed in terms of two <length> specifications, and these specifications must be expressed as non-per centage, definite lengths using pixel units. In order to specify the root container extent given the definition above should modify following state ment in [Dmedia] [Dmedia] Track Header Box ( tkhd ) The width and height SHALL be set (using fixed point values) to the width and height values of the tts:extent associated wi th the document root tt element, or if not present, with the tts:extent of the region specified on the body element, SHALL determi ne the spatial extent of the root container region, normalized to square pixel values if tt:pixelaspectratio is not equal to the value 1. The spatial extent of the root container region SHALL be set to the same value for all tt docs in a single track.

13 track header matrix Need to change the following statements to allow for t rack header matrix value changes [Dmedia] Track Header Box The following fields SHALL have their default value defined in [ISO]: layer, alternate_group, volume, matrix, Track_enabled, Track_ in_movie and Track_in_preview. [Dmedia] Track Header Box Other template fields excluding matrix SHALL be set to thei r default values.

14 translation matrix example: with PAR=squ are pixel Video track header: Vw: Video track width, Vh: Video track height matrix: {0x ,0,0, 0,0x ,0, Vx,Vy,0x } Subtitle track header: Sw: Subtitle track width, Sh: Subtitle track height matrix: {0x ,0,0, 0,0x ,0, Sx,Sy,0x } Region tts:extent width, height: Ew, Eh tts:origin: (Ox, Oy) ISOBMFF co-ordinate Sy origin Root container Vy co-ordinate origin e.g. (Sx,Sy) = (0,0) Video track co-ordinate origin e.g. (Vx,Vy) = (0,Vy) SxVx Oy Ox Sw Vw Video track Ew Region area tts:origin (Ox, Oy) Eh Vh Sh

15 Subtitle PAR PD, HD profile shall only allow square pixels SD profile: Square pixels and also allow PAR 40:33(854/704) 10:1 1(640/704) Use case: Re-use legacy SD subtitle assets(dvd etc.) e.g. Root container 704x480 -> normalize to track header square pixe l widthxheight: 854x480 or 640x480 e What happens to rendered text? i.e. will device render text in 704x480 and then scale to 854x480 etc(strec h text sideways)?

16 Subtitle/Chapter Time for video sync

17 Clarification of timeline for timed text Status Subtitle to video timeline mapping requires clarification Technical detail Timed text can use timeexpression if supported Time code can be used to represent subtitle display e.g. <P begin= 00:30:01 dur= 1s > abcdef </P> Need mapping to video CT(PTS) for synchronization SMPTE time code with drop/non-drop frame is likely to cause confusi on for synchronization with video composition time(ct)

18 Clarification of timeline for timed text Proposal A) Assign media time to the start of the video track presentation(composition time) B)Use only a specific time expression i.e. use tick or real time(no SMPTE drop frame etc.) e xpression only The tick or real time indicates the distance from the st art of the video track presentation(composition)

19 Ex) Real Time [0-9]+/.[0-9]+ Assuming subtitle event time is real time(media time) and unit is seconds. Note: real time is not commonly used in authoring nor for representing time in players. Assuming video with media TimeScale of 90kHz and media sample duration of 3003 Mapping subtitle event begin time= secs to video 1) subtitle event time to media time Media time= * ) Derive matching video AU from Basemediadecodetime + sumdt + CT offset = normalized composition time(nct) The subtitle event time will map to the smallest video frame NCT where NCT >= Media tim e

20 Ex) tick Assuming subtitle and video use the same tickrate/medi a TimeScale (90kHz) Mapping Subtitle event begin= ticks to video 1) Derive matching video AU from Basemediadecodetime + sumdt + CT offset = normalized composition time(nct) The subtitle event time will map to the smallest video fra me NCT where NCT >= Media time

21 [Dmeta] Chapter EntryTimeCode Element Attribut e Definition Value Card EntryTimecod e Entry point for chapter start Xs:string, pattern [0-9]+\.[0-9]+ EntryTimecode corresponds with a constrained form of the media timebase defined in [TTML], Section , and corresponds with the beginning of the chapter in the video and/or audio tracks for which the chapters are identified. In the case of a rounding error that doesn t result in an integer number of frames, the video and/or audio frame(s) EntryTimecode refers to shall be the next decodable frame after the time in the media referenced by this value. For example, in a 30fps progressive video track, 0.1 = the 3rd frame = the 4th frame. Proposal: Need clarification that metric is seconds.

22 Font pre-load buffer

23 Font pre-load buffer Should authors expect that there will be implementati ons where only one font family(file) is loaded to a limit ed size font pre-load buffer? If 2 or more font families are used in a tt doc and the devic e carries all font family files, will switching fonts cause play back to pause etc. due to re-loading font files? Proposal: May need implementation guide to limit only 1 font family p er subtitle track?

24 SMPTE TT

25 SMPTE TT filename extension Status st2052-1, says: If the URI reference is external to the document, then the filename ext ension in the URI shall provide a hint to the encoding type of the image using one of the MIME types in Table 9 This shall statement with the filename extension is not follow ed in the CFF spec, since each image is referenced by its su b-sample index in the subs. Proposal: Change the above shall statement to should in SMPTE T T