[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Re: Comments on draft-ietf-avt-rtp-3gpp-timed-text-04.txt
Hi Jose,
Comments inline:
Jose Rey wrote:
4. Section 2.3.4: I think the tables of possible combinations to
[snip]
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.
Okay, as long as there valid reasoning behind this, I don't see a
problem of leaving it as it is.
I only count the interarrival jitter as affected by the low resolution.
Is
there anything else?
Yes, I have also located the RFC 3611, RTCP XR measurement for RTP
arrival timestamping that has this property.
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...
Then there is no need to have a start value at all. And the attempt to
define a start value would be meaningless.
However you say that there is a need for a start value. This due to that
the SIDX must be monotonically increased depending on restrictions in
the 3GPP TS. Therefore I would like to have some further clarification
on what a start value actually is. To my understanding it is the SIDX
value that represent the first Sample description that are used. And
then as each new sample description is used, it must have a higher SIDX.
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." ?
The problem is that any declarative parameter does normally in
Offer/Answer only apply for the stream that the declaring entity is
going to receive. While the parameters present in the MIME registration
needs to apply in the other direction.
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.
No, I am not talking about if they are declarative or negotiated. In
fact there is no difference between "sendrecv" and "recvonly" in an
offerer when it comes to declarative parameters. In both stream types,
the declarative parameter apply to the stream that will be incoming to
the offerer.
It is only declarative parameters in a sendonly stream in that are
different, they provide preferences for how the offerer would desire to
send things. It is the answerers declarative values, that will decide
how the offerer will need to send the stream to the answerer.
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?
The usage you are proposing, would not change how O/A as I think. It is
a little confusing on the exact case we are discussing. As stated above,
the offerer and answer can use different values for declarative parameters.
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 I can agree that they are linked together and needs to be set
consistent. However the problem I am trying to explain is that the
entity needing to set them is the sending entity rather then the
receiving one.
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?
Yes, the clock rate is a negotiated parameter. Lets assume an offer that
looks like this:
m=video x RTP/AVP 96
a=rtpmap: 96 3gpp-tt/50
a=recvonly
a=fmtp 96 ...
Now it is the answerer that is going to send a stream to the offerer,
however its stream is stored on a file that assume the clock rate is
1000 Hz. As the answerer must use the same value, he will either have to
refuse the session or perform a answer like below that does not match
his stream:
m=video x RTP/AVP 96
a=rtpmap: 96 3gpp-tt/50
a=sendonly
a=fmtp 96 ...
So the point is that, unless you have the possibility to rewrite the TS
values, and SDUR fields you can't be certain that you can send a stream
that is being negotiated in the offer/answer model.
If one looks at the 3GPP timed text parameters, one would need to have
something like H.264, and define the following parameters:
rate: the RTP timestamp clockrate is equal to the clockrate of the
media. If RTP packets are generated out of a 3GP file, the
clockrate of the text media MUST be copied from the 3GP file,
i.e. the clockrate is the value of "timescale" parameter in the
Media Header Box describing that text track. Other tracks
(audio/video/text) in the 3GP file may have their own clockrates
as indicated in their corresponding Media Header Box. For live
encoding, a clockrate of 1000 Hz is RECOMMENDED but other values
MAY be used.
sver=<Z1(x1*256+y1)>, <Z2(x2*256+y2), ..., <Zi(xi*256+yi)>,...
The parameter "sver" specifies the list of supported backwards-
compatible versions of the timed text format specification (3GPP
TS 26.245), which the
**"receiver"** (instead of sender)
supports (or is willing to accept).
The first value is the current value used or the preferred
value. This MAY be followed by a comma-separated list of
increasingly older versions that SHOULD be used as alternatives.
The order is meaningful, being first most preferred and last
least preferred. Regarding the value calculation: "Zi" is the
number of the Release, "xi" and "yi" are taken from the 3GPP
specification version, i.e. vZi.xi.yi. For example, for 3GPP TS
26.245 v6.0.0, Zi(xi*256+yi)=6(0), the version value is "60".
Note that "60" is the concatenation of the values Zi=6 and
(xi*256+yi)=0 and not its product.
sprop-sver= The version and compatible version of the stream
actually going to be sent.
sprop-width=<integer-value>, indicates the width in pixels of the text
track or area where the text is actually displayed. This is a
16 bit integer.
maxwidth= The max display width in pixels that can be received.
sprop-height=<integer-value>, indicates the height in pixels of the
text
track. This is a 16 bit integer.
max-height= The max display height in pixels that can be received.
sprop-tx=<integer-value>, indicates the horizontal translation
offset in
pixels of the text track with respect to the origin of the video
track. This is a 16 bit integer.
.
sprop-ty=<integer-value>, indicates the vertical translation offset in
pixels of the text track. This is a 16 bit integer.
sprop-layer=<integer-value>, indicates the proximity of the text
track to
the viewer. Higher values means closer to the viewer. This
parameter has no units. This is a 16 bit integer.
Optional parameters:
spldesc=<value> indicates the way the server sends the sample
descriptions. This parameter MAY not be present, this meaning
that the value "both" is used. In detail:
o "out": all sample descriptions are sent out-of-band, e.g. in
the SDP. This may be used when the total number of sample
descriptions used is low. This is useful, e.g., for those
clients that want to choose a simple text stream.
o "both":, where both, in- and out-of-band, mechanisms MAY be
used. Note that "spldesc=both" indicates that both in-band
and out-of-band sample descriptions MAY be sent for that
stream, and not that both are necessarily sent during a
session. This corresponds to the default case. This is the
default case.
sprop-tx3g=<base64-value-1>, <base64-value-2>,...This parameter MUST be
used for conveying sample descriptions out-of-band. The list of
sample entries MAY follow any particular order and it MAY be
empty. The absence of this parameter is equivalent to an empty
list of sample descriptions. The <base64-value-i> represents
the base64 encoding of the concatenation of the SIDX and the
sample description for that SIDX, in this order. The format of
a sample description entry can be found in 3GPP TS 26.245
Release 6 and later releases. All servers and clients MUST
understand this parameter and MUST be capable of using the
sample description(s) contained in it. Please refer to RFC 3548
[6] for details on the base64 encoding.
I don't now if there is any usage of a tx3g parameter. In that case,
that would mean, here is the sample descriptions that you shall use to
send me timed text.
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