Subject: [AVT] Issues in Timed Text draft

From: "Jose Rey" <[email-masked]>
Date: Wed, 25 Feb 2004 15:07:25 +0100

Hi all,

these are the issues on which I would like to get some feedback
during/before the meeting:

- design rationale: a text sample consists typically of a text string
followed by some modifiers (decoration).  Associated to a text sample there
may be several (or none) sample descriptions.  The draft defines headers to
convey both whole text samples and fragments thereof (note that
fragmentation should be rare).  The draft allows only text string fragments
to be displayed individually. This meaning that if you receive a single text
string fragment out of three you may use/display it.  Unlike the case where
you don't receive some fragment(s) of the decoration: in this case you
SHOULD not use it/them, because it is not required that decoration be
splitted at meaningful boundaries (this was in the -01 draft and thought too
complex for the rare cases of fragmentation). See also section 4.1 in draft.
Comments?

- ordering of text sample contents: the modifier fragments don't contain
timing attributes (because they apply to text strings which already have
them, then why repeat?). Sample descriptions (which may apply to more than
one text sample) don't have them either.  Currently the draft allows to
place these modifier fragments and sample descriptions anywhere and as often
as needed.  This is useful, for example, to specially protect some parts of
the text sample or to send in advance the modifiers of a very long piece of
text. For live streaming this might not be the best method as the timing is
tight but for streaming it is a valid option. Problems with that?
Note that IDs (SIDX) are used to match fragments without timing attributes
to their text samples. See also Section 4.1

- resilient transport: of course apart from repeating the fragments in
different packets as above you may also repeat the packets themselves,
protect them using FEC or retransmit them.  The first two shall be more
apppropriate for streaming scenarios where a pre-determined packetisation
exists previous to transmission. See sections 4.1 and 5.  The implementer
SHALL ensure that the different pieces meet the timing requirements when
they are spread over several packets.

- TYPE=3: the draft explictly prohibits combining text strings and modifiers
in a fragment. The reason is simplicity:  since text strings shall be
capable of being displayed individually it would be necessary to introduce a
field in the header that explicitly says where the first byte of modifiers
is.  This is avoided by forcing the first modifiers fragment to be indicated
by means of a dedicated header type, TYPE=3. See section 4.2. Comments?

- In-band vs. out-of-band: the draft currently specifies two possibilities
to transport sample descriptions: in-band and out-of-band.  While
out-of-band is mandatory, the same does not apply to in-band.  However how
about making the two mandatory? (i.e. header TYPE=5).  At first we thought
of in-band just for live streaming of text.  But it also makes sense for
pre-packaged content. Both mandatory?

- Payload header design (section 4.2): the draft specifies an AU-like
payload structure (similar to RFC3640 for compatibility).  Currently there
are 5 payload header types

TYPE 1 : for whole text samples
|R|U|L|TYPE|{LEN}|SIDX|SDUR| 5-7 bytes long

TYPE 2: for text string fragments

|R|U|L|TYPE|{LEN}|SIDX|SLEN|SDUR|TOTL|THIS| 8-10 bytes long

TYPE 3&4: for first modifier fragment (TYPE=3) and subsequent fragments.

|R|U|L|TYPE|{LEN}|TOTL|THIS| 2-4 bytes long

TYPE 5: for sample descriptions.

|R|U|L|TYPE|{LEN}|SIDX| 2-4 bytes long

One could say that these be reduced to three by making the TOTL/THIS counter
refer to the number of fragments of a text string and modifier boxes in a
text sample instead of the total of fragments, like this:

[NOTE: {} means optional || fixed]

TYPE 1 : for whole text samples and fragments
|R|U|L|TYPE|{LEN}|SLEN|SIDX|SDUR|TOTL|THIS| 8-10 bytes long

TYPE 2: for ALL modifier fragments

|R|U|L|TYPE|{LEN}|TOTL|THIS| 2-4 bytes long

TYPE 3: for sample descriptions.

|R|U|L|TYPE|{LEN}|SIDX| 2-4 bytes long

The benefit, if any, is that the number of headers is reduced . Some
disadvantages are: an increase in the average header size (assuming that
fragmentation is rare), a more complex use of TOTL/THIS and of the SLEN/LEN
fields.  Another disadvantage is that it should be more costly for RFC 3640
to identify the AUs because TOTL/THIS is in the "AU-data contents" part.

So, at the moment we don't see a clear motivation to change to this header
configuration. Comments?

Thanks for your comments,

-------------------------------
Jose Rey
Mobile Multimedia Team
Panasonic European Labs GmbH
D-63225 Langen, Germany
Tel.:+49-6103-766-134
Fax :+49-6103-766-166
Email: [email-masked]
Visit: www.pel.panasonic.de
-------------------------------

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Wed, 25 Feb 2004 23:00:02 +0100

Umm this timed text, what is it for exactly?
Text telephony?
Or?

Thanks

Drs. Arnoud A. T. van Wijk
Viataal
Research & Development
Afdeling RDS
Theerestraat 42
5271 GD Sint-Michielsgestel
The Netherlands. 
Mobile: +31651921948
International text telephone: +31735588408

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jose Rey
Sent: woensdag 25 februari 2004 15:07
To: [email-masked]
Cc: Jan van der Meer; Dave Singer; Rolf Hakenberg; Magnus Westerlund; Per
Frojdh
Subject: [AVT] Issues in Timed Text draft

Hi all,

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 25 Feb 2004 23:21:57 +0100

Subtitling in stored media.
That is why it is timed. Timed to the part of video it belongs to.

Gunnar.

-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Arnoud
van Wijk
Sent: Wednesday, February 25, 2004 11:00 PM
To: 'Jose Rey'; [email-masked]
Cc: 'Jan van der Meer'; 'Dave Singer'; 'Rolf Hakenberg'; 'Magnus
Westerlund'; 'Per Frojdh'
Subject: RE: [AVT] Issues in Timed Text draft

Thanks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jose Rey
Sent: woensdag 25 februari 2004 15:07
To: [email-masked]
Cc: Jan van der Meer; Dave Singer; Rolf Hakenberg; Magnus Westerlund; Per
Frojdh

Hi all,

---

From: Dave Singer <[email-masked]>
Date: Thu, 26 Feb 2004 08:25:16 +0100

>Umm this timed text, what is it for exactly?

It's used for captioning, karaoke, titling etc., that is displayed 
text that is timed to go with other media (such as video).  There is 
provision for simple scrolling, highlighting, etc.

-- 
David Singer
Apple Computer/QuickTime

---

From: "Jose Rey" <[email-masked]>
Date: Thu, 26 Feb 2004 10:24:40 +0100

Arnoud,

check

http://www.ietf.org/internet-drafts/draft-rey-avt-3gpp-timed-text-02.txt

and its references for further details.  Also, there is a nice introduction
section on the usage.

Jose

> From: Dave Singer [mailto:[email-masked]]
> Sent: Thursday, February 26, 2004 8:25 AM
> To: Arnoud van Wijk; 'Jose Rey'; [email-masked]
> Cc: 'Jan van der Meer'; 'Rolf Hakenberg'; 'Magnus Westerlund'; 'Per
> Frojdh'

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Thu, 26 Feb 2004 12:12:29 +0100

Aaaah I now understand. :-)
Well I am very much interested in subtitling. Since I depend on that as a
deaf person.

Greetz

Arnoud

-----Original Message-----
From: Dave Singer [mailto:[email-masked]] 
Sent: donderdag 26 februari 2004 8:25
To: Arnoud van Wijk; 'Jose Rey'; [email-masked]
Cc: 'Jan van der Meer'; 'Rolf Hakenberg'; 'Magnus Westerlund'; 'Per Frojdh'
Subject: RE: [AVT] Issues in Timed Text draft

-- 
David Singer
Apple Computer/QuickTime