Subject: [AVT] timed text RTP payload

From: [email-masked]
Date: Mon, 23 Jun 2003 11:36:36 +0200

Remarks & questions

[
        2.  Transmit the text sample size, sample duration and sample
   description index in-band.  In 3GP format this information is
   included in the header part.  In RTP it is important to transmit it
   in-band because this information might change from sample to sample.
]

I think you should explicit that it is not a dangerous thing to do because
this information affects only the data in the packet
so when you loose a packet you do not loose the context...

it is rather obviously true for size and duration,
but less obvious for description index, i.e. as you
mention it in the section 1.2 a timed text stream
may transport samples using several different "descriptions"
(i.e. configurations) and it is therefore required
to indicate for each sample the "number" (index) of the
corresponding description.

BTW the sentence "In 3GP format this information is
   included in the header part" is misleading in this respect...

**************

[

      4.  Enable the multiplexing of text samples in one single RTP
   packet.  In a mobile communication environment a typical text sample
   size is around 100 bytes.  Thus, multiplexing several text samples
   makes the transport over RTP more efficient.
]

I think you should replace "multiplex" with "aggregation",
multiplex hints at something much more "drastic" than what you
want to achieve i.e. mixing several different streams together,
which comes with a whole lot of difficult issues etc :-)

**************

Questions

*  How does a receiver know if the first element of the payload is a FHDR or a THDR ?

* Figure 3.2 has two cases, both are 32 bits aligned, is it a requirement ?
otherwise how is the header aligned (with padding ?)

* section 4 *recommends* redundancy, I would leave that more open ...
anyway would you consider the possibility that the payload format itself
would enable redundancy by simply allowing "repeat"
(of, say some highly valuable "sentences" ?)

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

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

---

From: "Jose Rey" <[email-masked]>
Date: Mon, 23 Jun 2003 15:48:18 +0200

Thanks Philippe for your comments,

please see my answers inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Sent: Monday, June 23, 2003 11:37 AM
> To: [email-masked]
> Subject: [AVT] timed text RTP payload
>
>
>
> Remarks & questions
>
> [

yes. this is explained in the section 1.2 with

"..and the Sample to Chunk Box is mapped to the field SIDX (Text Sample
Entry Index).  The Sample to Chunk Box (stsc) associates the text sample
and its corresponding sample description entry in the Sample Description
Box (stsd, see below).  The Sample to Chunk Box can be used to associate
a text sample with a sample description entry...
"

If more than that is needed, I can add some comment when ellaborating on
the resilient transport section.

> corresponding description.

exactly..

>    included in the header part" is misleading in this respect...

Not only that... it is even incorrect :)

Thanks for the catch!

> which comes with a whole lot of difficult issues etc :-)

"issue" is a word I don't like :) I'll change it to "aggregation".

You look at the payload type field in the RTP header:

Section 3:

"The RTP sender implementing this payload format sends fragmented and
non-fragmented text samples using two different payload types, i.e.
payload type multiplexing, which are mapped dynamically.  For this
purpose, a new parameter is specified in this document for SDP,
"fragment", see Section SDP.  The receiver recognises a fragmented text
sample by the payload type value.  Note that this fact does not conflict
with Section 5.2 of RTP [5] because it is the same media that is being
transmitted.
"

If the RTP packet cotnains non-fragmented samples then there's only
THDRs, otherwise FHDR is always before THDR (see Fig. 1.2.)

> otherwise how is the header aligned (with padding ?)

Not at all. For example if Length(SIDX)=Length(SLEN)=Length(SDUR)=8
bits, the header is 24bits long and this is a valid combination.

> (of, say some highly valuable "sentences" ?)

how about something like:

"3GPP Timed Text operates at low bit rates.  For this reason the use of
redundancy is RECOMMENDED.  Redundancy can be achieved in different
manners. For example, redundant information can be piggybacked as per
RFC 2198 [6], coded into new packets achieving FEC (Forward Error
Correction) as per RFC 2733 [7] or the sending application MAY decide to
repeat some text sample fragments it deems important to provide packet
loss resiliency.  Furthermore, other redundancy schemes not listed here
might be applicable and defined in other documents."

looking forward to your comments,

Jose

> http://www.platform4.philips.com

Jose Rey____ mailto:[email-masked]
Mobile Multimedia Team -  MCOM Group
Panasonic European Laboratories GmbH
Tel: +49(0)6103-766-134
Fax: +49(0)6103-766-166
http://www.pel.panasonic.de
____________________________________