[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] timed text RTP payload
Thanks Philippe for your comments,
please see my answers inline...
> -----Original Message-----
> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of
> philippe.gentric@philips.com
> Sent: Monday, June 23, 2003 11:37 AM
> To: avt@ietf.org
> Subject: [AVT] timed text RTP payload
>
>
>
> 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...
>
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.
> 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.
>
exactly..
> BTW the sentence "In 3GP format this information is
> included in the header part" is misleading in this respect...
>
> **************
Not only that... it is even incorrect :)
Thanks for the catch!
>
>
> [
>
> 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 :-)
>
"issue" is a word I don't like :) I'll change it to "aggregation".
> **************
>
> Questions
>
> * How does a receiver know if the first element of the
> payload is a FHDR or a THDR ?
>
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.)
> * Figure 3.2 has two cases, both are 32 bits aligned, is it a
> requirement ?
> 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.
>
> * 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" ?)
>
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
>
> regards,
>
>
> Philippe Gentric
> Software Architect
> Philips MP4Net
> philippe.gentric@philips.com
> http://www.platform4.philips.com
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
Jose Rey____ mailto:rey@panasonic.de
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
____________________________________
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt