[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] RFC 3984 offer/answer Question
Roni,
Regarding the communication symmetric - if we understand it the way
which you propose (which I think is the practical one):
Offerer support up to level 3.
Offerer -> Answerer SDP message:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; packetization-mode=0;
Answerer support level 1 only.
Answerer -> Offerer SDP message:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A00A; packetization-mode=0;
There can be 2 possibilities:
1. The offerer must transmit in level 1.0. Still the answerer can
transmit up to level 3.0 if he wants.
2. Both of them must use level 1.
Which one is correct?
Yuval
-----Original Message-----
From: Even, Roni [mailto:roni.even at polycom.co.il]
Sent: Thursday, August 16, 2007 09:36
To: Randell Jesup
Cc: Yuval Nissan; ctrobianni at ecotronics.com; avt at ietf.org;
stewe at stewe.org
Subject: RE: [AVT] RFC 3984 offer/answer Question
Randell,
I can see your point but I would like to see other opinions maybe from
the authors of the text.
My view is that most current implementation of offer / answer for
unicast has the same approach. (this is based on interoperability tests
between vendors of video conferencing systems)
The problem here is that the profile-level-id parameter includes three
different parameters.
I still think that on the level part of the parameter the comparison
should be based on the highest common. I do not believe that the
intention here was to fix a specific mode.
Since the level parameter is an upper bound and lower levels are
included (except for level 1b) it does not make sense to offer a
separate media type for each level (there are 15 levels defined), for
example if the offerer support level 3 it will need to specify 3,2.2,
2.1, 2, 1.3, 1.2, 1.1 and 1 using 8 media type.
I do not think that this was the intention in offer/answer. Offer/answer
should not be used to fix a specific level.
To make it more complicated, by using the other optional parameters like
max-mbps, max-fs the meaning of the level according to table A.1 in
H.264 is changed and the current maximum values supported are based on
the sum of the values from table A.1 and the optional parameters.
BTW: I do not think that having the same level in the offer and answer
will make the communication symmetric, the encoder on each side can send
any frame size at any macro blocks per second rate that falls within the
specified level (this means frame size and frame rate would not be the
same on each direction).
If you want to have a specific picture size or frame rate (e.g. CIF at
30 fps) then you will need a different signaling for requesting specific
mode. I mentioned in Chicago that we are working in H.323 on such
extensions (requesting a specific mode (picture size and frame rate))
and we will have a similar draft for SDP based systems.
Roni Even
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
A consensus means that everyone agrees to say collectively what no one
believes individually
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com]
> Sent: Wednesday, August 15, 2007 8:58 PM
> To: Even, Roni
> Cc: Yuval Nissan; ctrobianni at ecotronics.com; avt at ietf.org;
stewe at stewe.org
> Subject: Re: [AVT] RFC 3984 offer/answer Question
>
> "Even, Roni" <roni.even at polycom.co.il> writes:
> >"If the offerer wants to support only level 1.0" - this is not the
case
> >here. The offerer can support level 3. The answerer can support only
> >level 1 which is implied by the offer. The parameter value is
supported.
> >This is why the answerer maintains the configuration parameters.
>
> My apologies if I wrote too quickly - I was on the way to pick up my
> mother-in-law at the hospital (after 10 weeks). I should have said
> "if the offerer wants to also support level 1.0". It should have
> been clear from the context, but I mis-stated it.
>
>
> The offerer supports Level 3.0, and in the original question, only
> includes
> a single payload and FMTP at 3.0. According to 8.2.2 (below), you
MUST
> use
> profile-level-id symmetrically (along with packetization-mode and
maybe
> sprop-deint-buf-req). The answer MUST not change any of them, or it
must
> remove the payload if it cannot support them. So, when offered level
3,
> an
> answerer who supports level 1 MUST remove the level 3 payload.
>
> Accordingly (and per the much longer full section 8 of the RFC and RFC
> 3264, I think if you want to support levels 1-N you must offer levels
1-N
> as separate payloads (N payloads). If you want to support
> packetization-modes 0 and 1 as well, you'll need 2*N payloads.
>
> I wish I'd been looking at this before it was approved, though given
> general offer-answer semantics it's not too surprising they chose this
> way.
>
> >> I think that's invalid for offer/answer, per 8.2.2. If the offerer
> >> wants to support only level 1.0 (in this case, 42a00a), it *has* to
> >> offer it as a separate payload type in the offer. The answer
cannot
> add
> >> it as the same payload type, and you're not supposed to add media
> >> formats (payloads) in an answer.
> >>
> >>
> >> 8.2.2. Usage with the SDP Offer/Answer Model
> >>
> >> When H.264 is offered over RTP using SDP in an Offer/Answer
model
> [7]
> >> for negotiation for unicast usage, the following limitations and
> >> rules apply:
> >>
> >> o The parameters identifying a media format configuration for
H.264
> >> are "profile-level-id", "packetization-mode", and, if
required by
> >> "packetization-mode", "sprop-deint-buf-req". These three
> >> parameters MUST be used symmetrically; i.e., the answerer
MUST
> >> either maintain all configuration parameters or remove the
media
> >> format (payload type) completely, if one or more of the
parameter
> >> values are not supported.
> >>
> >> Informative note: The requirement for symmetric use
applies
> >> only for the above three parameters and not for the other
> >> stream properties and capability parameters.
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga
OS
> team
> rjesup at wgate.com
> "The fetters imposed on liberty at home have ever been forged out of
the
> weapons
> provided for defence against real, pretended, or imaginary dangers
from
> abroad."
> - James Madison, 4th US president (1751-1836)
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt