[AVT] RE: Comments on draft-ietf-avt-rtp-3gpp-timed-text-04.txt

["Jose Rey" <rey at panasonic.de>]

Hi Magnus,

please see inline.

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund at ericsson.com]
> Sent: Monday, July 26, 2004 6:43 PM
> To: Jose Rey
> Cc: IETF AVT WG; matsui.yoshinori at jp.panasonic.com; Dave Singer; Jan van
> der Meer
> Subject: Re: Comments on draft-ietf-avt-rtp-3gpp-timed-text-04.txt
>
>
> Hi Jose,
>
> Comments below:
>
> Jose Rey wrote:
>
> >>4. Section 2.3.4: I think the tables of possible combinations to send
> >>has a problem. I would think that sending a packet with first a type 2
> >>and then a type 3 fragment would be desirable. It seems the most
> >
> > likely
> >
> >>fragmentation scenario is after all that the modifiers are to big. In
> >>that case it seems desirable to start with the text, and then as much
> >>modifiers that fits the MTU.
> >>
> >
> >
> > What you propose is only possible if the fragments belong to different
> > text
> > samples.  For fragments of the same text sample it is not possible since
> > the
> > TYPE 3 has a duration field and the timestamp calculation wouldn't work.
> > The
> > reason for including the SDUR is that it should be known to the receiver
> > when these fragments should be discarded.  Otherwise, receiver buffer
> > may
> > contain fragments of unknown expiration time.
> >
> > One can argue that a fragment of the next packet could be included then,
> > e.g., a TYPE3 from text sample 2 with a TYPE2 of text sample 1, but for
> > simplicity I did not want to do this: the next or previous sample may
> > actually not need fragmentation or even not have any modifiers, so that
> > at
> > the end it will probably make no difference and it does seem more
> > complex.
> >
>
> Okay, I understand. How severe is this limitation? It seems that in a
> scenario when not sending redundancy, the fragmentation might force you
> to send a first very in efficient type 2 packet for the text part,
> followed by another packet that is slightly over MTU, forcing you to
> send two modifier packets, for a total of 3 packets. While it could have
> been sufficient with 2. However I also don't like strange rules. My
> suggestion for solving this would be to actually include both SDUR and
> timestamp offset. Thus allowing presence of multiple packet types from
> the same timestamp. Also allowing redundancy skipping certain samples. I
> don't know which impact such a solution would have.
>
> >

I would expect that both text strings and modifiers could get big, as
indicated in the draft.

Your comments above are legitimate in any case, however I assume in the
draft the fragmentation rate is so low that it is not worth to do this.

The impact to include a timestamp offset would not be very big, but I think
this is not worth the effort.


[snip]

> >
> >>And the thing that many may not think of is the measuring through
> >
> > RTCP.
> >
> >
> > ??
> > You mean I should mention that synchronisation of media is done with
> > RTCP?
> > Do I need to mention this?
> >
>
> Sorry, me being fuzzy. What I mean is that if the RTP timestamp rate is
> to low, this results in problems for some of the RTCP measurements as
> their resolution is locked to the RTP payload rate.
>
> Thus I think you with the recommendation to use 1000 Hz should also
> include as statement declaring that with lower timestamp rates some RTCP
> measurements may be effected due to low resolution.
>

I only count the interarrival jitter as affected by the low resolution.  Is
there anything else?

> [snip]
> >
> >>9. Section 3.1.2:
> >>   "Note that also empty text samples are considered whole text
> >
> > samples,
> >
> >>    although they do not contain sample contents.  In this particular
> >>    case, TYPE 1 units MUST NOT include any sample contents and the
> >
> > LEN
> >
> >>    field SHALL have a value of 8 (0x0008).  Otherwise, the LEN field
> >>    SHALL be always greater than 8 (0x0008)."
> >>
> >>Here is one place where some motivation why to send empty could be
> >>included. Also I think the normative text is maybe a bit to much. It
> >>seems rather obvious that an empty text sample will not contain any
> >>sample contents and will have a length of 8. If some text should be
> >>written on this, I think an informative sentence is better:
> >>"A Type 1 units without sample contents will have LEN field value of 8
> >>(0x0008).
> >>
> >
> > You mean better than the SHALL above?
>
> I would say so, this is over usage of the normative word. If one follows
> the definition of the LEN field it becomes obvious that this is the
> values that will be used. So therefore if you like to put some emphasis
> on that empty packets are allowed, that is sufficient to perform using
> text without normative words.
>
OK

> [snip]
>
> >
> >>11. Section 3.1.2:
> >>"The default start value MUST be 129. "
> >>
> >>What is the meaning with the sentence. What is the start value?
> >>Is what
> >>you mean the following: "When assigning static sample descriptions
> >
> > SIDX
> >
> >>values, they SHOULD start at 129."
> >
> >
> > Yes except for the SHOULD, I think..
> >
> >
> >>I don't think MUST is possible to
> >>support, and seems to provide no benefit.
> >>
> >
> >
> > why? When reading out of a 3GP file, you can rewrite the SIDX anyway and
> > when encoding live putting 129 is the same as putting any other value
> > there.
> > Missing anything?
> >
> > The original thought was to make it a MUST, so that you have the whole
> > interval available.  OK, you will never use the 126 values available it
> > but
> > there is no reason to make it shorter...On the other hand, if you make
> > them
> > random you might get a random value of 254 which just allows 1 static
> > sample
> > description and we didn't define a wrap-up mechanism for static because
> > this
> > is really not necessary.  Why not just fix it and get rid of the
> > problems?
> >
>
>
> Okay, we are on different pages. My first question regarding the
> definition of a start value, seem to be the springing point here.
>
> If a start value, is the first SIDX used, and there exist a restriction,
> that any subsequent SIDX value used must be higher, then your comment
> holds.

This is the case. Thus no problem.

>However if there exist no restrictions on how you use the SIDX
> values, then it is not a problem.

?? the both are not a problem? I'm lost...

> Example:
>
> Definition section defines:
> 255 148 127, in that order.
>
> The texting stream uses the SIDX values in the following order:
>
> 148 255 127.
>
> If that is not a problem, there is no need for any care about start
> values and what is defined.
>
>
>
> >
> >>19. Section 8.2.1:
> >>   "This means that an offerer using these
> >>    parameters only specifies which values are going to be used for
> >
> > the
> >
> >>    sent stream."
> >>
> >>I hope you are aware of that you are changing the direction of how
> >>parameters normally work in offer-answer.
> >
> >
> > I am not sure what you mean.  This may need further discussion depending
> > on
> > the answer to the one below.
> >
>
> In a sendrecv case, when the offerer gives a stream. The actual values
> of parameters he provides is what he accepts to receive.

OK, let's see:

Is the problem you are referring to in the following sentence (Section
8.2.1): "  The answerer MAY include these parameters or not in its answer.
If included, the values MAY be different." ?

As I understand you mean that if the offerer 'offers' a sendrecv stream and
the answerer accepts it, this means the answerer must either include the
parameters verbatim in the answer or else remove the stream?

However, if the stream offered is recvonly, the answerer may either change
the parameters (downgraded or equal) or else remove the stream?

This interpretation clashes with some past discussion
(http://www1.ietf.org/mail-archive/web/avt/current/msg03364.html) where
declarative is meant as something that both may use with different values.
That may be the problem.

I acknowledge that if the above is correct it is a much simple exchange, but
I don't know how 'O/A-compliant' this is...



> For parameters
> applicable that works in the direction, of what the declaring entity
> sends does not fit very well. For example the offerer has to declare
> them prior to knowing what the answerer is accepting to receive.
>

Actually I thought in a sendrecv stream, the answerer can use different
parameter values for the stream it sends from those for the stream it
receive (I am basing this in the email referenced)... that's why I included
the sentence in quotes above.  But as I understand from your comments, this
would mean a change in how O/A works, and an extra message from offerer to
receiver, right?


> >>I toiled rather much with the H.264 offer answer section,
> >>and did basically define two versions of some parameters. The reason
> > is
> >>that there is cases where the receiver would like to specify that it
> >>want to receive a timed text that fits a certain screen size. While
> >>often it is the sender that will declare what format the stream going
> > to
> >>be delivered will have. So the question if this functionality is
> > needed.
> >
> >
> > Let me answer you with a counter question ;) Typically, text and video
> > will
> > go together in many applications: in video applications, is it
> > usual/normal
> > to negotiate the picture size for video instead of choosing from a list
> > of
> > possibilities in an SDP (similar to example 10.2 in RFC 3264)? If
> > negotiation is the common thing because there are so many different
> > possible
> > sizes, it makes sense to let these parameters express preference,
> > similar to
> > what is done with the parameter sets included in the h264 profile
> > parameter
> > (right?).   Otherwise if the options are typically a few I can keep it
> > as
> > is. What do you think?
>
> But video sizes are in the offer/answer model are not negotiated. I
> think they are simply declared by the receiver. Or at least the
> parameters that effect them. See for example the MPEG-4 elementary
> stream config string, that although missing offer/answer can only be
> interpreted as declared parameters to apply for the stream that is
> accepted to be received (in a sendrecv case).

Again, inline with my comment above, does this meant that the answerer
accepting the sendrecv stream will use the same 'config'? If so, this is
clearly easier.

>
> It is clear that at least one of parameters are clearly needed to be
> declared in the senders direction: tx3g. This is something the sender
> determines, in fact they seem to be rather similar to H.264's parameter
> sets. Also this idealistic case does assume live encoding. If one uses
> stored streams, also the size and rate parameters need to be declared.

I think all tx,ty,layer,tx3g and height,width are of the same type. One
could think of negotiating each other differently but since they all refer
to display, a change in one of them might also mean changes in the other
ones, e.g., if you change the position of the text track you have to take
care that the new position doesn't go over the screen, else reduce the
size..etcetera.  I think it makes little sense to have 'fine granularity'
here.


> I think it may in fact be a serious problem to not have a defined RTP
> timestamp rate.

The timestamp clockrate is always included in the offer and it MUST be
accepted or else the whole stream removed, where's the problem?

> Because I have no idea how to actually allow fit into
> the model the possibility to declare the timestamp rate on what one
> intends to send.

??

>
> The problem is really Offer/Answer and SDP, possibly also SIP. The fact
> is that we need a two phase negotiation in some cases. First one
> declares one capabilities and preferences. Then in the second phase, one
> declares what actual configuration matching the capabilities and
> preferences one is going to use.
>
> I don't know if you managed to get any wiser on these comments. We
> should discuss this face to face.


Partly...I'll be glad to discuss this face-to-face.  If you can provide me
some comments in the mean time I will advance some work.

Thanks,

Jose
>
>
> Cheers
>
>
> Magnus Westerlund
>
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
>



_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt