Subject: [AVT] Q for 3984bis-06

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 11 May 2009 14:08:25 -0700

Page 12 says:

         Informative note: Because H.264 allows the decoding order to 
         be different from the display order, values of RTP timestamps 
         may not be monotonically non-decreasing as a function of RTP 
         sequence numbers.  Furthermore, the value for inter-arrival 

This is not something specific for H.264 content. It applies to almost all codecs. A rewording may be beneficial IMO. 

         jitter reported in the RTCP reports may not be a trustworthy 
         indication of the network performance, as the calculation 
         rules for inter-arrival jitter (section 6.4.1 of RFC 3550) 
         assume that the RTP timestamp of a packet is directly 
         proportional to its transmission time.

What does it mean that RTP timestamp is proportional to its transmission time? By "transmission time" do you mean the instant the packet was sent? By definition, timestamp reflects the sampling instant of the first octet in the RTP packet. The packets belong to a single video frame will most likely have the same timestamp. But that does not mean that they will be transmitted at the same time.

RFC 3550 has a simple rule here and says this rule must be followed. The packets are considered in the order they arrive, not based on their seqnums in the jitter calculation. And the parameters needed to compute the interarrival jitter are clock rate, timestamp and arrival-time timestamp.

I suggest a revision for this informative note, or we can simply remove it since section 6.4.4 of RFC 3550 already provides a more-than-sufficient explanation. 

-acbegen

---

From: Ye-Kui Wang <[email-masked]>
Date: Mon, 11 May 2009 17:27:34 -0400

Thanks Ali. This is an intact inheritance from RFC 3984. I'd agree to remove
the note in the next submission. 

BTW, AVT Chairs, what is the plan on progressing this and the SVC drafts?

BR, YK 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ali C. Begen (abegen)
> Sent: Monday, May 11, 2009 5:08 PM
> To: [email-masked]
> Subject: [AVT] Q for 3984bis-06
> 
> Page 12 says:
> 
> This is not something specific for H.264 content. It applies 
> to almost all codecs. A rewording may be beneficial IMO. 
> 
> What does it mean that RTP timestamp is proportional to its 
> transmission time? By "transmission time" do you mean the 
> instant the packet was sent? By definition, timestamp 
> reflects the sampling instant of the first octet in the RTP 
> packet. The packets belong to a single video frame will most 
> likely have the same timestamp. But that does not mean that 
> they will be transmitted at the same time.
> 
> RFC 3550 has a simple rule here and says this rule must be 
> followed. The packets are considered in the order they 
> arrive, not based on their seqnums in the jitter calculation. 
> And the parameters needed to compute the interarrival jitter 
> are clock rate, timestamp and arrival-time timestamp.
> 
> I suggest a revision for this informative note, or we can 
> simply remove it since section 6.4.4 of RFC 3550 already 
> provides a more-than-sufficient explanation. 
> 
> -acbegen
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 12 May 2009 09:58:10 +0200

I was waiting for the discussion of level upgrade to settle. Should I issue a 
summary of what I have seen so far?

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 12 May 2009 09:50:26 -0400

Yes, please go ahead. 

BR,YK 

> From: Tom Taylor [mailto:[email-masked]] 
> Sent: Tuesday, May 12, 2009 3:58 AM
> To: Ye-Kui Wang
> Cc: 'Ali C. Begen (abegen)'; [email-masked]; [email-masked]
> Subject: Re: [AVT] Q for 3984bis-06
> 
> I was waiting for the discussion of level upgrade to settle. 
> Should I issue a summary of what I have seen so far?
> 
> Ye-Kui Wang wrote:
> > Thanks Ali. This is an intact inheritance from RFC 3984. 
> I'd agree to 
> > remove the note in the next submission.
> > 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >> Ali C. Begen (abegen)
> >> This is not something specific for H.264 content. It applies to 
> >> almost all codecs. A rewording may be beneficial IMO.
> >>
> instant the 
> >> packet was sent? By definition, timestamp reflects the sampling 
> >> instant of the first octet in the RTP packet. The packets 
> belong to a 
> >> single video frame will most likely have the same 
> timestamp. But that 
> >> does not mean that they will be transmitted at the same time.
> >>
> followed. 
> >> The packets are considered in the order they arrive, not based on 
> >> their seqnums in the jitter calculation.
> >> And the parameters needed to compute the interarrival jitter are 
> >> clock rate, timestamp and arrival-time timestamp.
> >>
> >> I suggest a revision for this informative note, or we can simply 
> >> remove it since section 6.4.4 of RFC 3550 already provides a 
> >> more-than-sufficient explanation.
> >>
> >> -acbegen
> >>

---

From: Ye-Kui Wang <[email-masked]>
Date: Mon, 18 May 2009 11:57:39 -0400

Tom, All,

Let me try to give a summary of the discussion of level upgrade. To my
understanding, there has been no clear conclusion that level upgrade is
absolutely needed, and there has been no clear proposal that has no issue.
For support of the original use case Ashish Goyal proposed, which is copied
below for convenience, there is no need to change anything in the draft

"Here is how the use case is expected to work. 
  Assume the video device A is able to decode level 3.1 and encode only
level 1.1
  B is capable of both decoding and encoding level 3.1. 
  A would quote a level of 3.1 in its offer
  B would respond with level 3.1 in the answer
  A would send to B video stream at level 1.1 - since A can only encode at
level 1.1. 
  B would send level 3.1 to A since A can decode upto level 3.1."

Therefore, my take is not to make any change in this regard. Any different
opinions?

BR,YK

> Behalf Of Ye-Kui Wang
> Sent: Tuesday, May 12, 2009 9:50 AM
> To: 'Tom Taylor'
> Cc: [email-masked]; [email-masked]
> > >> Audio/Video Transport Working Group [email-masked]

---

From: stephen botzko <[email-masked]>
Date: Mon, 18 May 2009 12:12:39 -0400

This makes sense to me.

Of course it does not apply to profiles, since the profiles are not intended
to form a hierarchy.  But the levels do form a hierarchy - the ability to
decode level 3.1 of a given profile implies the ability to decode all lower
levels.

Regards,
Stephen Botzko

---

From: Randell Jesup <[email-masked]>
Date: Mon, 18 May 2009 14:45:31 -0400

>absolutely needed, and there has been no clear proposal that has no issue.

How about this (may need a little wordsmithing):

   Level upgrade

   An offerer who wishes to allow level-upgrade in the answer can include
   "max-level=XX" in the fmtp line (XX is the level in hex, as it is in the
   middle of profile-level-id).  An answerer may not increase the level in
   the response unless the offerer included max-level, and may not increase
   the level beyond XX.  Other receive fmtp parameters such max-fs, etc
   shall apply to all levels and SHOULD not be lower than the minimum
   values required by the level specified in max-level.

And add max-level to the list of fmtp params.

Normal requirements for sprop-parameter-sets/sprop-level-parameter-sets
would apply, or in-line as per normal.

Simple, will not break any 3984 (or current 3984-bis) answerer.

>Therefore, my take is not to make any change in this regard. Any different

That use-case doesn't *need* upgrade, agreed..  The one that does (or where
you gain an advantage from) is the inverse case, where something limits the
size/etc an offerer wants to decode.

Here's the relevant case: Assume this is a a device with a fixed LCD size,
or configured to play in a small window on a larger display.
------------------------
Assume the video device A is only reasonably able to decode level 2.0, due
to display limitations (QCIF LCD), but can encode up to level 3.1.
B is capable of both decoding and encoding level 3.1. 
A would quote a level of 2.0 in its offer, including max-level=1F
B would respond with level 3.1 in the answer
A would send to B video stream at level 3.1
B would send level 2.0 to A since A can only decode up to level 2.0

Otherwise, A would either need to only offer 2.0 (and only send 2.0), even
if it has an HD camera and the destination is an HD room conference system
that can display level 5.0.

You can't set max-fs lower than the min for the level offered, nor
max-mbps, so you can't limit the received bitstream in that manner.  In
theory you might be able to limit the received bitstream crudely via
b=AS:NN, but that's up to the sender to notice, comply with, and even then
it doesn't mean they won't send "too large" a framesize at a lower
framerate or higher quantization.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"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)

---

From: Ye-Kui Wang <[email-masked]>
Date: Mon, 18 May 2009 16:49:56 -0400

Inline below. 

> From: Randell Jesup [mailto:[email-masked]] 
> Sent: Monday, May 18, 2009 2:46 PM
> To: Ye-Kui Wang
> Cc: 'Tom Taylor'; [email-masked]; [email-masked]

What is the semantics of max-level? Would the semantics of profile-level-id
change?

> Normal requirements for 
> sprop-parameter-sets/sprop-level-parameter-sets
> >For support of the original use case Ashish Goyal proposed, which is 
> >copied below for convenience, there is no need to change anything in 
> >the draft
> >
> >  A would send to B video stream at level 1.1 - since A can 
> only encode 
> >at level 1.1.
> >Therefore, my take is not to make any change in this regard. Any 
> >different opinions?
> 
> That use-case doesn't *need* upgrade, agreed..  The one that 
> does (or where you gain an advantage from) is the inverse 
> case, where something limits the size/etc an offerer wants to decode.
> 
> Here's the relevant case: Assume this is a a device with a 
> fixed LCD size, or configured to play in a small window on a 
> larger display.
> ------------------------
> Assume the video device A is only reasonably able to decode 
> level 2.0, due to display limitations (QCIF LCD), but can 
> encode up to level 3.1.

Decoding is different and typically decoupled from display. For example, a
mobile device may be equipped with HD recording and decoding capability, but
it needs an external HD display (e.g. a TV) to really display HD. However,
in the absence of an HD display, the device can still still decode what it
recorded but just display it in a small screen. In your example, does the
video device has the capability to decoded up to level 3.1 at all?

> A would quote a level of 2.0 in its offer, including 
> max-level=1F B would respond with level 3.1 in the answer A 
> would send to B video stream at level 3.1 B would send level 
> 2.0 to A since A can only decode up to level 2.0
> 
> Otherwise, A would either need to only offer 2.0 (and only 
> send 2.0), even if it has an HD camera and the destination is 
> an HD room conference system that can display level 5.0.
> 
> You can't set max-fs lower than the min for the level 
> offered, nor max-mbps, so you can't limit the received 
> bitstream in that manner. 

I don't understand this. 

BR,YK

> In theory you might be able to 
> limit the received bitstream crudely via b=AS:NN, but that's 
> up to the sender to notice, comply with, and even then it 
> doesn't mean they won't send "too large" a framesize at a 
> lower framerate or higher quantization.
> 
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), 
> ex-Amiga OS team [email-masked] "The fetters imposed on 
> liberty at home have ever been forged out of the weapons

---

From: Randell Jesup <[email-masked]>
Date: Tue, 19 May 2009 10:57:57 -0400

>What is the semantics of max-level? Would the semantics of profile-level-id

max-level is an offerer-only parameter, since it's used by the receiver to
generate an answer.  It does not change the semantics of profile-level-id
(beyond that an answer can use a higher level).

>video device has the capability to decoded up to level 3.1 at all?

The video device may have the *capability* to decode level 3.1 (in terms of
raw horsepower), but it may not have the capability to both decode and scale
it down, and more importantly it may not want to use up the bandwidth and
horsepower (at the sender and on the network, and/or it's own battery
power) to receive HD when it can only display a much smaller resolution.

Think of a battery-powered device w/ 802.11.  Why spend the bandwidth on
the air to receive HD, and the battery power to decode and scale HD, when
you're displaying 640x480 (or lower)?  You still may want to send HD if
you're calling into an HD conference room or HD-capable endpoint.  Also, in
a multi-party conference situation, the conference server will want to
minimize bits sent and horsepower for encoding streams, so this may be a
win.

On a more general level, what was the purpose in not allowing upgrade in
the first place?  I think it wasn't explicit; originally neither downgrade
nor upgrade were allowed, and downgrade was dealt with first because there
are obvious and more-common uses for downgrade.

This should have *no* impact on existing implementations; you can safely
ignore max-level when making an answer.

>> bitstream in that manner. 

If you offer level 2.1, you are not allowed to use max-fs/etc to restrict
the received bitstream to a lower framesize/etc than level 2.1 supports.
You can only increase the framesize/etc over the level offered:

   The value of max-fs MUST be greater than or equal to the value of MaxFS
   for the level given in Table A-1 of [1].

So you can't say "I support level 2.2 but I only want to receive a
framesize of CIF (the max size in level 2.0)".  Level 2.2 would allow
receiving CIF at ~50fps; if you offer level 2.0 instead, the answerer can't
send you anything beyond 30fps.  But you can't offer 2.2 without allowing
the answerer to send you 4CIF at 12fps, which you would just have to scale
down to CIF anyways.  

This is a real-world case; devices often have more encode horsepower (and
camera resolution) than they can actually display when receiving, and they
talk to other devices that *can* display that extra resolution..

---

From: "Jonathan Lennox" <[email-masked]>
Date: Tue, 19 May 2009 11:51:39 -0400

Why is max-level (with a value) needed, as opposed to something like
level-upgrade-allowed?  Remember the level sent by a receiver is still
only an upper bound on what the transmitter is allowed to send.

Architecturally, I think it would be cleanest if H.264's non sprop-*
parameters all have SDP's standard receive-side semantics, rather than
offer/answer semantics.

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

> Sent: Tuesday, May 19, 2009 10:58 AM
> To: Ye-Kui Wang
> Cc: [email-masked]; 'Tom Taylor'; [email-masked]
> max-level is an offerer-only parameter, since it's used by the
receiver
> to
> generate an answer.  It does not change the semantics of
profile-level-
> id
> provided for defence against real, pretended, or imaginary dangers
from
> abroad."

---

From: stephen botzko <[email-masked]>
Date: Tue, 19 May 2009 11:53:16 -0400

In our experience, the reverse situation is what actually happens - PCs for
instance frequently can decode and display HD images, but are often limited
to an SD webcam.
Can you name a couple of specific real devices that have these HD
cameras+encoders and the limited decoders?

Steve

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 19 May 2009 12:15:43 -0400

> Architecturally, I think it would be cleanest if H.264's non 
> sprop-* parameters all have SDP's standard receive-side 
> semantics, rather than offer/answer semantics.

In that case, sprop-* parameters indicate stream properties, others indicate
basically receiving capabilities (I guess this is what you mean by SDP's
standard receive-side semantics). If someone wants to indicate sending
capabilities, then another group of parameters is needed. Hmm, this way it
may work better, but it seems too late to do this now, maybe for future
codecs. 

BR, YK 

> From: Jonathan Lennox [mailto:[email-masked]] 
> Sent: Tuesday, May 19, 2009 11:52 AM
> To: Randell Jesup; Ye-Kui Wang
> Cc: [email-masked]; Tom Taylor; [email-masked]
> Subject: RE: [AVT] Q for 3984bis-06
> 
> Why is max-level (with a value) needed, as opposed to 
> something like level-upgrade-allowed?  Remember the level 
> sent by a receiver is still only an upper bound on what the 
> transmitter is allowed to send.
> 
> Architecturally, I think it would be cleanest if H.264's non 
> sprop-* parameters all have SDP's standard receive-side 
> semantics, rather than offer/answer semantics.
> 
> --
> Jonathan Lennox
> Vidyo, Inc
> [email-masked]
> 
> 
> > >recorded but just display it in a small screen. In your 
> example, does
> > the
> > raw horsepower), but it may not have the capability to both 
> decode and
> > scale
> > it down, and more importantly it may not want to use up the 
> bandwidth
> > and
> > Think of a battery-powered device w/ 802.11.  Why spend the 
> bandwidth
> > on
> > minimize bits sent and horsepower for encoding streams, so 
> this may be
> > a
> > win.
> > 
> > On a more general level, what was the purpose in not 
> allowing upgrade
> > in
> > receiving CIF at ~50fps; if you offer level 2.0 instead, 
> the answerer
> > can't
> > camera resolution) than they can actually display when 
> receiving, and
> > they
> > Randell Jesup, Worldgate (developers of the Ojo 
> videophone), ex-Amiga
> > OS team
> > [email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Tue, 19 May 2009 12:24:09 -0400

>cameras+encoders and the limited decoders?

Mostly I'm not talking PC's (I agree with you there, though there are cases
where it still may make sense, like when displaying video in a portion of
the screen).  I'm mostly talking mobile and dedicated devices with built-in
LCDs; that would include Smartphones, dedicated videophones, "media"
tablets, etc.

For example, certain devices have been made with two different LCDs; one
~850x480, the other ~480x234, both with VGA-class cameras.  Sending VGA
content (or really anything beyond CIF) to the 480x234 display is just a
waste of bits.  If you wanted to and could negotiate it properly, though,
you could send higher framerate CIF to that device, while it sends VGA at a
lower framerate to a device that can show it.

As for the comment about max-level=NN versus level-upgrade-allowed: I'd
originally thought level-upgrade-allowed made the most sense, and in fact
probably it does - let the answer respond with the highest level they can
receive, and the offerer can send at whatever level they support.  

That's even easier to describe:

  level-upgrade-allowed=0 or 1:
         If the offer sets level-upgrade-allowed to 1, then an answer may
         include any level above the offered level in profile-level-id.
         The offerer may send at any level up to the level in the answer,
         and and answerer can send levels only up to the level in the
         offer.  If this is not present or is set to 0, then the answer
         MUST NOT respond with a level greater than the level in
         profile-level-id.  

         Note that this only allows the level to be increased in the
         answer; the profile and constraints are not allowed to change.

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 19 May 2009 13:57:24 -0400

I see immediately the following problems with the semantics, without yet
considering all possible cases. 

>          include any level above the offered level in 

Only when the offer and the answer both include level-upgrade-allowed equal
to 1, it is allowed for the answer to include a higher level. In all other
cases, level upgrade is not allowed. 

>          The offerer may send at any level up to the level in 

This does not work with the current semantics of profile-level-id (part of
which copied below for convenience). 

"The profile-level-id parameter indicates the default sub-profile, i.e. the
subset of coding tools that may have been used to generate the stream or
that the receiver supports, and the default level of the stream or the
receiver supports."

According to the current semantics of profile-level-id, the level part of
the profile-level-id in the offer limits what the offerer can receive. 

>          offer.  

What if the answerer has a receiving capability between the two levels in
the offer and the answer or lower than the level in the offer, and it wants
the receiving capability expressed?

BR, YK

> If this is not present or is set to 0, then 
> the answer

> Sent: Tuesday, May 19, 2009 12:24 PM
> To: stephen botzko
> Cc: Ye-Kui Wang; [email-masked]; Tom Taylor; [email-masked]
> >This is a real-world case; devices often have more encode horsepower 
> >(and camera resolution) than they can actually display when 
> receiving, 
> >and they talk to other devices that *can* display that extra 
> resolution..
> >>>>
> >
> >In our experience, the reverse situation is what actually 
> happens - PCs 
> >for instance frequently can decode and display HD images, 
> but are often 
> >limited to an SD webcam.
> Mostly I'm not talking PC's (I agree with you there, though 
> there are cases where it still may make sense, like when 
> displaying video in a portion of the screen).  I'm mostly 
> talking mobile and dedicated devices with built-in LCDs; that 
> would include Smartphones, dedicated videophones, "media"
> tablets, etc.
> 
> For example, certain devices have been made with two 
> different LCDs; one ~850x480, the other ~480x234, both with 
> VGA-class cameras.  Sending VGA content (or really anything 
> beyond CIF) to the 480x234 display is just a waste of bits.  
> If you wanted to and could negotiate it properly, though, you 
> could send higher framerate CIF to that device, while it 
> sends VGA at a lower framerate to a device that can show it.
> 
> 
> As for the comment about max-level=NN versus 
> level-upgrade-allowed: I'd originally thought 
> level-upgrade-allowed made the most sense, and in fact 
> probably it does - let the answer respond with the highest 
> level they can receive, and the offerer can send at whatever 
> level they support.  
>

---

From: Randell Jesup <[email-masked]>
Date: Tue, 19 May 2009 15:00:15 -0400

Ye-Kui Wang <[email-masked]> writes:
>>          If the offer sets level-upgrade-allowed to 1, then an answer
>>          may include any level above the offered level in
>>          profile-level-id.
>

Why is level-upgrade-allowed required in the response?  The level upgrade
is signaled (or not) via the profile-level-id value returned in the answer;
there's no need for an additional parameter in the answer.  

>the profile-level-id in the offer limits what the offerer can receive. 

Right...  That doesn't change; there's no conflict here.  The answerer
answers with a higher level, but the answerer is still not allowed to
*send* a level above that provided in the offer.  The answerer may
*receive* a stream up to the level they put in the answer.  That's the
whole point here.

>the receiving capability expressed?

Using level-upgrade-allowed=1 (the current proposal) means there is only
one level in the offer (profile-level-id).  If the answerer wants to
downgrade the level in the response, they may do so (as per current),
regardless of level-upgrade-allowed.  If they want to upgrade it, they can
pick whatever level they're willing to receive and respond with that.  They
will send the level in the offer (or below).

Perhaps this table will help:

Offer is level "B".  I'll use level "A" to indicate a lower level, and "C"
for a higher one (A < B < C).  I'm assuming the offer includes
level-upgrade-allowed=1.

 Answer level:     lower (A)       same (B)       higher (C)

Offerer can send:     A              B               C
Answerer can send:    A*             B               B

*This could be 'B' if we decide the same asymmetry is allowed for
level-downgrade as well, when level-upgrade-allowed=1.  (We could rename it
level-asymmetry-allowed if we want that ability.)

Current behavior, and if there's no level-upgrade-allowed (or it's 0):

 Answer level:     lower (A)       same (B)       higher (C)

Offerer can send:     A              B             Not Allowed
Answerer can send:    A              B             Not Allowed

>> >In our experience, the reverse situation is what actually happens - PCs
>> >for instance frequently can decode and display HD images, but are often
>> >limited to an SD webcam.  Can you name a couple of specific real
>> >devices that have these HD cameras+encoders and the limited decoders?
>> 
>>          If the offer sets level-upgrade-allowed to 1, then an answer
>>          may include any level above the offered level in
>>          profile-level-id.  The offerer may send at any level up to the
>>          level in the answer, and and answerer can send levels only up
>>          to the level in the offer.  If this is not present or is set to
>>          0, then the answer MUST NOT respond with a level greater than
>>          the level in profile-level-id.
>>

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 19 May 2009 16:12:14 -0400

Inline. 

> Sent: Tuesday, May 19, 2009 3:00 PM
> To: Ye-Kui Wang
> Cc: 'stephen botzko'; [email-masked]; 'Tom Taylor'; 
> [email-masked]
> >I see immediately the following problems with the semantics, without 
> >yet considering all possible cases.
> >
> >Only when the offer and the answer both include 
> level-upgrade-allowed 
> >equal to 1, it is allowed for the answer to include a higher 
> level. In 
> >all other cases, level upgrade is not allowed.
> 
> Why is level-upgrade-allowed required in the response?  The 
> level upgrade is signaled (or not) via the profile-level-id 
> value returned in the answer; there's no need for an 
> additional parameter in the answer.  
> 

For backward compatibility. Inclusion of level-upgrade-allowed to 1 (or
another parameter) indicates that an entity is not a legacy device which
does not understand the new parameter. Otherwise, you have to make sure that
the mechanism works in all the four cases:

offerer answerer
new	new
new	legacy
legacy	new
legacy  legacy

Note that these are orthogonal to the three cases your listed below.
Basically all the 12 cases (and there are other dimentions of variations,
e.g. the last point I made in this email) must be well analyzed for such a
seemingly non-backward-compatible change.

> >This does not work with the current semantics of 
> profile-level-id (part 
> >of which copied below for convenience).
> >
> >"The profile-level-id parameter indicates the default 
> sub-profile, i.e. 
> >the subset of coding tools that may have been used to generate the 
> >stream or that the receiver supports, and the default level of the 
> >stream or the receiver supports."
> >
> >According to the current semantics of profile-level-id, the 
> level part 
> >of the profile-level-id in the offer limits what the offerer 
> can receive.
> 
> Right...  That doesn't change; there's no conflict here.  The 
> answerer answers with a higher level, but the answerer is 
> still not allowed to
> *send* a level above that provided in the offer. 

The conflict is at the offerer's side. It includes a lower level, but you
are proposing requires that the offerer can receive a higher level. To do
this, you must change the current semantics of profile-level-id.

> The answerer may
> *receive* a stream up to the level they put in the answer.  
> That's the whole point here.
> 

This point is contradicting with other places, where the answerer may
receive a stream up to the level in the offer (not in the answer).

> >What if the answerer has a receiving capability between the 
> two levels 
> >in the offer and the answer or lower than the level in the 
> offer, and 
> >it wants the receiving capability expressed?
> 
> Using level-upgrade-allowed=1 (the current proposal) means 
> there is only one level in the offer (profile-level-id).  If 
> the answerer wants to downgrade the level in the response, 
> they may do so (as per current), regardless of 
> level-upgrade-allowed.  If they want to upgrade it, they can 
> pick whatever level they're willing to receive and respond 
> with that.  They will send the level in the offer (or below).
> 
> for a higher one (A < B < C).  I'm assuming the offer 
> includes level-upgrade-allowed=1.
> 
> 

In the right case (the answer includes level C), what if the offerer's
receiveing capability is actually lower than C?

BR, YK

> *This could be 'B' if we decide the same asymmetry is allowed 
> for level-downgrade as well, when level-upgrade-allowed=1.  
> (We could rename it level-asymmetry-allowed if we want that ability.)
> 
> 
> >> If this is not present or is set to 0, then the answer
> happens - 
> >> >PCs for instance frequently can decode and display HD images, but 
> >> >are often limited to an SD webcam.  Can you name a couple of 
> >> >specific real devices that have these HD cameras+encoders 
> and the limited decoders?
> >> 
> >> Mostly I'm not talking PC's (I agree with you there, 
> though there are 
> >> cases where it still may make sense, like when displaying 
> video in a 
> >> portion of the screen).  I'm mostly talking mobile and dedicated 
> >> devices with built-in LCDs; that would include 
> Smartphones, dedicated 
> >> videophones, "media"
> >> tablets, etc.
> >> 
> different LCDs; 
> >> one ~850x480, the other ~480x234, both with VGA-class cameras.  
> >> Sending VGA content (or really anything beyond CIF) to the 480x234 
> >> display is just a waste of bits.
> >> If you wanted to and could negotiate it properly, though, 
> you could 
> >> send higher framerate CIF to that device, while it sends VGA at a 
> level-upgrade-allowed 
> >> made the most sense, and in fact probably it does - let the answer 
> >> respond with the highest level they can receive, and the 
> offerer can 
> >> send at whatever level they support.
> >>

---

From: Randell Jesup <[email-masked]>
Date: Tue, 19 May 2009 16:46:51 -0400

Ye-Kui Wang <[email-masked]> writes:
>> >Only when the offer and the answer both include level-upgrade-allowed
>> >equal to 1, it is allowed for the answer to include a higher level. In

If the offerer is legacy, then they don't include level-upgrade-allowed,
and as stated the answerer is not allowed to upgrade the level.  If the
answerer is legacy, then they will ignore level-upgrade-allowed, and won't
upgrade the level.  So those 3 cases are all handled.

>seemingly non-backward-compatible change.

Please see above.  Those additional cases are all covered.

>> >This does not work with the current semantics of profile-level-id (part
>> >"The profile-level-id parameter indicates the default sub-profile, i.e.
>> >According to the current semantics of profile-level-id, the level part
>> >of the profile-level-id in the offer limits what the offerer can
>> >receive.
>> 

No, unless we decide to take the option mentioned in my table (change it to
"level-asymmetry-allowed").  Then (and only then) could the offerer could
receive a level above what they offered.  

>> The answerer may *receive* a stream up to the level they put in the
>> answer.  That's the whole point here.
>

Heh?  In current 3984/3984bis usage, if the offer is level 2.0, and the
answer is level 1.0, how will the answerer receive anything above level
1.0?  Even in my proposal that's not allowed (unless we decide to use
level-asymmetry-allowed instead of level-upgrade-allowed).

>> >What if the answerer has a receiving capability between the two levels
>> >in the offer and the answer or lower than the level in the offer, and
>> Offer is level "B".  I'll use level "A" to indicate a lower level, and
>> "C" for a higher one (A < B < C).  I'm assuming the offer includes
>> level-upgrade-allowed=1.
>> 
>> 

Then they shouldn't answer with "C".  They should answer with whatever
level they do support.  The point of this is to allow the answerer to
offer to receive a higher level; they get to choose what that level is.

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 19 May 2009 17:17:22 -0400

I shortened the text. 

> upgrade the level.  So those 3 cases are all handled.

OK. But it is possible that the answerer is new but does not want to upgrade
the level in an offer/answer process. It would be certainly useful that the
answerer lets the other side know whether it is new or legacy. Therefore,
I'd prefer to include level-upgrade-allowed equal to 1 if the device is new
(does understand the parameter and allows level upgrade). Note that
something is allowed does not mean it is in use. 

> receive a level above what they offered.  

Sorry, I mis-read your table. But that just makes a difference on receiving
or sending capability, not the conclusion. In the righ case in the table
(i.e. offer includes B, and answer includes C). The current semantics say
that the offerer would only be able to send B and lower. But you want the
offerer to be able to send C which is higher than B.

> offer to receive a higher level; they get to choose what that 

Now with the correct reading of the table. Again, that just makes a
difference on receiving or sending capability, not the conclusion. You are
basically assuming that the offerer's sending (i.e. encoding) capability is
not limited, i.e. it can send whatever high level the answer may include.
How can that assumption be correct?

BR, YK

---

From: Randell Jesup <[email-masked]>
Date: Wed, 20 May 2009 00:29:15 -0400

Ye-Kui Wang <[email-masked]> writes:

>> answerer is legacy, then they will ignore level-upgrade-allowed, and
>> won't upgrade the level.  So those 3 cases are all handled.
>

The answerer could do that, and I don't have a problem with it (it doesn't
hurt anything), but I don't see how it's useful in any way.

>> >The conflict is at the offerer's side. It includes a lower level, but
>> >you are proposing requires that the offerer can receive a higher
>> >level. To do this, you must change the current semantics of
>> >profile-level-id.
>> 
>> No, unless we decide to take the option mentioned in my table (change it
>> to "level-asymmetry-allowed").  Then (and only then) could the offerer
>> could receive a level above what they offered.
>

I don't understand what you're trying to say here.  That's the point of
level upgrade.  And the offerer is still sending at a level specified in
the answers profile-level-id.  Perhaps you're just saying "yes, this means
the offerer might end up sending a stream at a higher level than it
offered", which is the whole point of level upgrade.

>> >> Offer is level "B".  I'll use level "A" to indicate a lower level,
>> >> and "C" for a higher one (A < B < C).  I'm assuming the offer

You need to think about how level works in H.264.

Remember we're only changing level, not constraints or profiles.

Levels imply details about the maximum frame size, maximum macroblocks per
second, maximum bitrate, etc, and each level is a superset of the
next-lower level.  Using a level doesn't mean you (as an encoder) have to
hit those maximums.  If you encode a stream using the parameters of a lower
level (i.e. using lower maximums), it's decodable by a higher-level
decoder, even if you set the parameter sets to the higher level.

Even more importantly, there's no apparent requirement to send exactly the
level given by the profile-level-id; sending lower levels (with the correct
profile and constraints) appears to be just fine (note that this interacts
with parameter-set handling - you need to deal with making sure the decoder
has correct parameter sets, as you always do).

>From 3984:

   If the profile-level-id parameter is used to indicate properties of a
   NAL unit stream, it indicates the profile and level that a decoder has
   to support in order to comply with [1] when it decodes the stream.

and

   If the profile-level-id parameter is used for capability exchange or
   session setup procedure, it indicates the profile that the codec
   supports and the highest level supported for the signaled profile.

Note "highest level". And:

   The level conveyed in the value of the profile-level-id parameter MUST
   be such that the receiver is fully capable of supporting.

and
   o  Parameters used for declaring receiver capabilities are in general
      downgradable; i.e., they express the upper limit for a sender's
      possible behavior.  Thus a sender MAY select to set its encoder
      using only lower/lesser or equal values of these parameters.
      [snip]
   o  Parameters declaring a configuration point are not downgradable,
      with the exception of the level part of the "profile-level-id"
      parameter.  This expresses values a receiver expects to be used
      and must be used verbatim on the sender side.

So, to summarize, if in response to an offer with level-upgrade-allowed=1,
the answer includes a level higher than the offerer supports:

* The offerer can encode a stream as if it's a higher level (including
  parameter sets), but using the encode settings of a lower level that it
  supports. 
* The offerer can encode a stream using a lower level, including
  lower-level parameter sets.

In both cases, the parameter sets must be conveyed to the answerer in some
manner; the mechanisms that would make the most sense are in-band parameter
sets (with all that implies), or using sprop-level-parameter-sets including
levels above the level in the offered profile-level-id, so that the answer
can select one of those levels and thus install those parameter sets.

None of this requires any further modification to 3984bis that I can see -
just allowing level-upgrade-allowed (or level-asymmetric-allowed).

---

From: Randell Jesup <[email-masked]>
Date: Wed, 20 May 2009 01:08:01 -0400

Ye-Kui Wang <[email-masked]> writes:
>> So, to summarize, if in response to an offer with 
>> level-upgrade-allowed=1, the answer includes a level higher 
>> than the offerer supports:
>> 
>>   parameter sets), but using the encode settings of a lower level that
>>   it supports.
>
>So, in your interpretation, the offerer sending a higher level just means
>that it sends sequence parameter sets containing the higher level, but the
>bitstream characteristics are still restricted by the lower level. How could
>this bring any practical usefulness? In the example, offer includes level B
>(e.g. spatial resolution up to QVGA), and the answer includes a higher level
>C (e.g. spatial resolution up to VGA), then both sides still send and
>receive up to QVGA resolution, but the offer includes sequence parameter
>sets include the level value C. Why is this useful at all?

You asked a different question:

>> >difference on receiving or sending capability, not the conclusion. You
>> >are basically assuming that the offerer's sending (i.e. encoding)
>> >capability is not limited, i.e. it can send whatever high level the
>> >answer may include.  How can that assumption be correct?

You asked about sending at "whatever high level the answer may include".
My response shows that you don't have to send at an arbitrarily-high level
- you can send at the highest level you support.

For example, if the offer is 1.3 with level-upgrade-allowed=1, and the
answer is level 3.1, then the offerer can send at any level up to and
including level 3.1.  It could send level 2.0 if that's the highest it can
encode.

>> Sent: Wednesday, May 20, 2009 12:29 AM
>> To: Ye-Kui Wang
>> >> If the offerer is legacy, then they don't include 
>> >> level-upgrade-allowed, and as stated the answerer is not 
>> allowed to 
>> >> upgrade the level.  If the answerer is legacy, then they 
>> will ignore 
>> >> level-upgrade-allowed, and won't upgrade the level.  So 
>> those 3 cases are all handled.
>> >
>> >OK. But it is possible that the answerer is new but does not want to 
>> >upgrade the level in an offer/answer process. It would be certainly 
>> >useful that the answerer lets the other side know whether it 
>> is new or 
>> >legacy. Therefore, I'd prefer to include 
>> level-upgrade-allowed equal to 
>> >1 if the device is new (does understand the parameter and 
>> allows level 
>> >upgrade). Note that something is allowed does not mean it is in use.
>> 
>> The answerer could do that, and I don't have a problem with 
>> it (it doesn't hurt anything), but I don't see how it's 
>> useful in any way.
>> 
>> >> >The conflict is at the offerer's side. It includes a lower level, 
>> >> >but you are proposing requires that the offerer can 
>> receive a higher 
>> >> No, unless we decide to take the option mentioned in my 
>> table (change 
>> >> it to "level-asymmetry-allowed").  Then (and only then) could the 
>> >> offerer could receive a level above what they offered.
>> >
>> >Sorry, I mis-read your table. But that just makes a difference on 
>> >receiving or sending capability, not the conclusion. In the 
>> righ case 
>> >in the table (i.e. offer includes B, and answer includes C). The 
>> >current semantics say that the offerer would only be able to 
>> send B and 
>> >lower. But you want the offerer to be able to send C which 
>> is higher than B.
>> 
>> I don't understand what you're trying to say here.  That's 
>> the point of level upgrade.  And the offerer is still sending 
>> at a level specified in the answers profile-level-id.  
>> Perhaps you're just saying "yes, this means the offerer might 
>> end up sending a stream at a higher level than it offered", 
>> which is the whole point of level upgrade.
>> 
>> >> >In the right case (the answer includes level C), what if the 
>> >> >offerer's receiveing capability is actually lower than C?
>> >> 
>> >> Then they shouldn't answer with "C".  They should answer with 
>> >> whatever level they do support.  The point of this is to allow the 
>> >> answerer to offer to receive a higher level; they get to 
>> choose what 
>> >> that level is.
>> >
>> >difference on receiving or sending capability, not the 
>> conclusion. You 
>> >are basically assuming that the offerer's sending (i.e. encoding) 
>> >capability is not limited, i.e. it can send whatever high 
>> level the answer may include.
>> Levels imply details about the maximum frame size, maximum 
>> macroblocks per second, maximum bitrate, etc, and each level 
>> is a superset of the next-lower level.  Using a level doesn't 
>> mean you (as an encoder) have to hit those maximums.  If you 
>> encode a stream using the parameters of a lower level (i.e. 
>> using lower maximums), it's decodable by a higher-level 
>> Even more importantly, there's no apparent requirement to 
>> send exactly the level given by the profile-level-id; sending 
>> lower levels (with the correct profile and constraints) 
>> appears to be just fine (note that this interacts with 
>> parameter-set handling - you need to deal with making sure 
>> the decoder has correct parameter sets, as you always do).
>> 
>> From 3984:
>> 
>> So, to summarize, if in response to an offer with 
>> level-upgrade-allowed=1, the answer includes a level higher 
>> than the offerer supports:
>> 
>> In both cases, the parameter sets must be conveyed to the 
>> answerer in some manner; the mechanisms that would make the 
>> most sense are in-band parameter sets (with all that 
>> implies), or using sprop-level-parameter-sets including 
>> levels above the level in the offered profile-level-id, so 
>> that the answer can select one of those levels and thus 
>> install those parameter sets.
>> 
>> None of this requires any further modification to 3984bis 
>> that I can see - just allowing level-upgrade-allowed (or 
>> level-asymmetric-allowed).
>> 
>> --

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 20 May 2009 00:54:42 -0400

BR, YK

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 20 May 2009 11:51:47 -0400

> For example, if the offer is 1.3 with 
> level-upgrade-allowed=1, and the answer is level 3.1, then 
> the offerer can send at any level up to and including level 
> 3.1.  It could send level 2.0 if that's the highest it can encode.

The whole point is, if the offer contians level 1.3 (per 3984 or the bis
draft) with sendrecv or no direction attribute, then level 1.3 is the
highest it can both encoded and encode. In this case, it simply cannot
encode above level 1.3. 

Text in 3984: 
                        If the profile-level-id parameter is used for
                        capability exchange or session setup procedure,
                        it indicates the profile that the codec
                        supports and the highest level
                        supported for the signaled profile.

BR, YK

> Sent: Wednesday, May 20, 2009 1:08 AM
> To: Ye-Kui Wang
> >> level-upgrade-allowed=1, the answer includes a level 
> higher than the 
> >> offerer supports:
> >> 
> >So, in your interpretation, the offerer sending a higher level just 
> >means that it sends sequence parameter sets containing the higher 
> >level, but the bitstream characteristics are still restricted by the 
> >lower level. How could this bring any practical usefulness? In the 
> >example, offer includes level B (e.g. spatial resolution up 
> to QVGA), 
> >and the answer includes a higher level C (e.g. spatial 
> resolution up to 
> >VGA), then both sides still send and receive up to QVGA 
> resolution, but 
> >the offer includes sequence parameter sets include the level 
> value C. Why is this useful at all?
> 
> conclusion. 
> >> >You are basically assuming that the offerer's sending (i.e. 
> >> >encoding) capability is not limited, i.e. it can send 
> whatever high 
> >> >level the answer may include.  How can that assumption be correct?
> 
> For example, if the offer is 1.3 with 
> level-upgrade-allowed=1, and the answer is level 3.1, then 
> the offerer can send at any level up to and including level 
> 3.1.  It could send level 2.0 if that's the highest it can encode.
> 
> >BR, YK
> >
> >> The answerer could do that, and I don't have a problem with it (it 
> >> doesn't hurt anything), but I don't see how it's useful in any way.
> >> 
> the point 
> >> of level upgrade.  And the offerer is still sending at a level 
> >> specified in the answers profile-level-id.
> >> Perhaps you're just saying "yes, this means the offerer 
> might end up 
> >> sending a stream at a higher level than it offered", which is the 
> >> whole point of level upgrade.
> >> 
> >> macroblocks per second, maximum bitrate, etc, and each level is a 
> >> superset of the next-lower level.  Using a level doesn't 
> mean you (as 
> >> an encoder) have to hit those maximums.  If you encode a 
> stream using 
> >> the parameters of a lower level (i.e.
> decoder, even 
> >> if you set the parameter sets to the higher level.
> >> 
> >> Even more importantly, there's no apparent requirement to send 
> >> exactly the level given by the profile-level-id; sending 
> lower levels 
> >> (with the correct profile and constraints) appears to be just fine 
> >> (note that this interacts with parameter-set handling - 
> you need to 
> >> deal with making sure the decoder has correct parameter 
> sets, as you 
> >> always do).
> >> 
> >> From 3984:
> >> 
> >>    If the profile-level-id parameter is used to indicate 
> properties 
> >> of a
> >>    NAL unit stream, it indicates the profile and level 
> that a decoder 
> >> has
> >>    If the profile-level-id parameter is used for 
> capability exchange 
> >> or
> >>    The level conveyed in the value of the profile-level-id 
> parameter 
> >> MUST
> >> level-upgrade-allowed=1, the answer includes a level 
> higher than the 
> >> offerer supports:
> >> 
> answerer in 
> >> some manner; the mechanisms that would make the most sense are 
> >> in-band parameter sets (with all that implies), or using 
> >> sprop-level-parameter-sets including levels above the level in the 
> >> offered profile-level-id, so that the answer can select 
> one of those 
> >> levels and thus install those parameter sets.
> >> 
> that I can 
> >> see - just allowing level-upgrade-allowed (or 
> >> OS team [email-masked] "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."
> ex-Amiga OS team

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 20 May 2009 12:07:12 -0400

Typo: encoded -> decode. So, the sentence should be as follows. 

" The whole point is, if the offer contians level 1.3 (per 3984 or the bis
draft) with sendrecv or no direction attribute, then level 1.3 is the
highest it can both encoded and encode. In this case, it simply cannot
encode above level 1.3. "

BTW, it is not absolutely prohibited to change the semantics of
profile-level-id, I am just saying that you need to change the semantics. In
addition, if the encoding/sending capability and the decoding/receiving
capability is different, both capabiilties should be expressed. One way is
to use different direction attributes (and separate SDP), which was
considered not perfect. The other way is, as I mentioned earlier, to use two
parameters, one for each. 

BR, YK

> Sent: Wednesday, May 20, 2009 11:52 AM
> To: 'Randell Jesup'
> Cc: [email-masked]; 'stephen botzko'; [email-masked]; 
> 'Tom Taylor'
> level-upgrade-allowed=1, and the 
> > including level 3.1.  It could send level 2.0 if that's the 
> highest it 
> > can encode.
> 
> draft) with sendrecv or no direction attribute, then level 
> 1.3 is the highest it can both encoded and encode. In this 
> case, it simply cannot encode above level 1.3. 
> 
> Text in 3984: 
> > My response shows that you don't have to send at an 
> arbitrarily-high 
> > level
> level-upgrade-allowed=1, and the 
> > including level 3.1.  It could send level 2.0 if that's the 
> highest it 
> > can encode.
> > 
> > >BR, YK
> > >
> > >>   parameter sets), but using the encode settings of a 
> lower level 
> > >> that it
> > >>   supports. 
> > OS team [email-masked] "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."

---

From: Roni Even <[email-masked]>
Date: Wed, 20 May 2009 19:40:34 +0300

YK,
An offer of level 1.3 is just an offer, it is not necessarily what the
device can do. The reasons  for offering a lower level can be due to
multiple reasons, like some configuration of the terminal and not based on
encoder/decoder performance.

Having said that I would like to point out that in most cases you can get
higher functionality by using other parameters like offering level 3.1 and
using max-fs, max-br and max-cpb parameter to offer support for HD picture
(using max-fs and max-cpb) at higher bit rate (based on max-br) which are
over level 3.1 according to table A-1 in H.264. This is very typical in
video conferencing applications if the offerer cannot support the maxBR for
level 4 in table A-1. 
I think that in this case it is reasonable for the answer to signal level 4
since it gives similar resolution but hinting that it can encode and decode
higher bit rate. This will not break interoperability and make it simpler
for the answerer.

Roni 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ye-Kui
Wang
Sent: Wednesday, May 20, 2009 7:07 PM
To: 'Randell Jesup'
Cc: [email-masked]; 'Tom Taylor'; 'stephen botzko'; [email-masked]
Subject: Re: [AVT] Q for 3984bis-06

BR, YK

> > lower level that

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 20 May 2009 13:24:49 -0400

Roni,

> From: Roni Even [mailto:[email-masked]] 
> Sent: Wednesday, May 20, 2009 12:41 PM
> To: 'Ye-Kui Wang'; 'Randell Jesup'
> An offer of level 1.3 is just an offer, it is not necessarily 
> what the device can do. The reasons  for offering a lower 
> level can be due to multiple reasons, like some configuration 
> of the terminal and not based on encoder/decoder performance.
> 

If this is the case, then the current semantics of profile-level-id is
simply incorrect as it reads. 

> Having said that I would like to point out that in most cases 
> you can get higher functionality by using other parameters 
> like offering level 3.1 and using max-fs, max-br and max-cpb 
> parameter to offer support for HD picture (using max-fs and 
> max-cpb) at higher bit rate (based on max-br) which are over 
> level 3.1 according to table A-1 in H.264. This is very 
> typical in video conferencing applications if the offerer 
> cannot support the maxBR for level 4 in table A-1. 

Correct. 

> I think that in this case it is reasonable for the answer to 
> signal level 4 since it gives similar resolution but hinting 
> that it can encode and decode higher bit rate. This will not 
> break interoperability and make it simpler for the answerer.

I don't think this is correct according to either RFC 3984 or the bis. As
you said earlier, it is allowed to signal level 3.1, and to use those max-*
parameters to indicate that the device has higher than 3.1 capability in a
particular aspect, but not the other way round. If you signal level 4, there
is no way to tell which aspect of the capability is lower than level 4. This
is simply not what the spec says. If you think this way should be supported,
you must propose it and make it said in the spec. 

BR, YK

> case, it simply cannot encode above level 1.3. "
> 
> BTW, it is not absolutely prohibited to change the semantics 
> of profile-level-id, I am just saying that you need to change 
> the semantics. In addition, if the encoding/sending 
> capability and the decoding/receiving capability is 
> different, both capabiilties should be expressed. One way is 
> to use different direction attributes (and separate SDP), 
> which was considered not perfect. The other way is, as I 
> mentioned earlier, to use two parameters, one for each. 
> 
> BR, YK
> 
> Behalf Of 
> > Ye-Kui Wang
> > Cc: [email-masked]; 'stephen botzko'; [email-masked]; 'Tom 
> > Taylor'
> > The whole point is, if the offer contians level 1.3 (per 
> 3984 or the 
> > bis
> > 1.3 is the highest it can both encoded and encode. In this case, it 
> > simply cannot encode above level 1.3.
> > 
> > Text in 3984: 
> > > >>    o  Parameters used for declaring receiver 
> capabilities are in 
> > > >> general

---

From: Roni Even <[email-masked]>
Date: Wed, 20 May 2009 20:59:42 +0300

YK,

The semantics of the parameters now is correct, what I was saying is that
there may be a difference between what a device is offering and what the
device can do in terms of processing, this can happen due to other decisions
like configuration and it may go higher if the other side indicates that it
can do so.

I think allowing level upgrade by the answerer is what all the people
discussing the topic draft are suggesting (Ingemar, Randell, Jonathan,
Magnus and others). I just gave another example where it can happen. 
Maybe clarify that the level is a receive capability will help.

Jonathan Lennox even suggests " Architecturally, I think it would be
cleanest if H.264's non sprop-* parameters all have SDP's standard
receive-side semantics, rather than offer/answer semantics."

Roni Even
-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Wednesday, May 20, 2009 8:25 PM
To: 'Roni Even'; 'Randell Jesup'
Cc: [email-masked]; 'Tom Taylor'; 'stephen botzko'; [email-masked]
Subject: RE: [AVT] Q for 3984bis-06

Roni,

Correct. 

BR, YK

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 20 May 2009 14:11:10 -0400

Roni,

Right, we are discussing possible approaches to acheive level upgrade. The
hottest one has been what Randell proposed (level-upgrade-allowed), but it
seems that there is something disconnecting Randell and myself, and we are
working hard to find that out :-) I believe all the discussions are good to
help us making a fully informed decision. 

BR, YK 

> Sent: Wednesday, May 20, 2009 2:00 PM
> The semantics of the parameters now is correct, what I was 
> saying is that there may be a difference between what a 
> device is offering and what the device can do in terms of 
> processing, this can happen due to other decisions like 
> configuration and it may go higher if the other side 
> indicates that it can do so.
> 
> I think allowing level upgrade by the answerer is what all 
> the people discussing the topic draft are suggesting 
> (Ingemar, Randell, Jonathan, Magnus and others). I just gave 
> another example where it can happen. 
> Jonathan Lennox even suggests " Architecturally, I think it 
> would be cleanest if H.264's non sprop-* parameters all have 
> SDP's standard receive-side semantics, rather than 
> offer/answer semantics."
> 
> Roni Even

---

From: Tom Taylor <[email-masked]>
Date: Wed, 20 May 2009 20:37:49 +0200

I think fairly soon Roni and I are going to have to call a consensus on this 
one. It's all very well to have discussion, but only if new points are coming 
out. I'll review the thread once more.

---

From: Roni Even <[email-masked]>
Date: Wed, 20 May 2009 21:55:59 +0300

YK,
Does this mean that you are considering adding level upgrade but just
arguing the text?

Anyhow Tom will need to call for a consensus on the change based on the long
discussion starting with the email from Ashish (May 4th)

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ye-Kui
Wang
Sent: Wednesday, May 20, 2009 9:11 PM
To: 'Roni Even'; 'Randell Jesup'
Cc: [email-masked]; 'Tom Taylor'; [email-masked]; 'stephen botzko'
Subject: Re: [AVT] Q for 3984bis-06

Roni,

BR, YK

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 20 May 2009 15:22:16 -0400

Roni,

> Does this mean that you are considering adding level upgrade 
> but just arguing the text?

Yes, unless it is finally concluded that there is no need or there is a big
problem that does not worth the addition.

BR, YK 

> Sent: Wednesday, May 20, 2009 2:56 PM
> Does this mean that you are considering adding level upgrade 
> but just arguing the text?
> 
> Anyhow Tom will need to call for a consensus on the change 
> based on the long discussion starting with the email from 
> Ashish (May 4th)
> 
> Roni
> 
> Right, we are discussing possible approaches to acheive level 
> upgrade. The hottest one has been what Randell proposed 
> (level-upgrade-allowed), but it seems that there is something 
> disconnecting Randell and myself, and we are working hard to 
> find that out :-) I believe all the discussions are good to 
> saying is 
> > that there may be a difference between what a device is 
> offering and 
> > what the device can do in terms of processing, this can 
> happen due to 
> > other decisions like configuration and it may go higher if 
> the other 
> > side indicates that it can do so.
> > 
> the people 
> would be 
> > > An offer of level 1.3 is just an offer, it is not 
> necessarily what 
> > > the device can do. The reasons  for offering a lower level can be 
> > > due to multiple reasons, like some configuration of the 
> terminal and 
> > > not based on encoder/decoder performance.
> > > 
> > 
> > > Having said that I would like to point out that in most cases you 
> > > can get higher functionality by using other parameters 
> like offering 
> > > level 3.1 and using max-fs, max-br and max-cpb parameter to offer 
> > > support for HD picture (using max-fs and
> > > max-cpb) at higher bit rate (based on max-br) which are 
> over level 
> > > 3.1 according to table A-1 in H.264. This is very typical 
> in video 
> > > conferencing applications if the offerer cannot support the maxBR 
> > > for level 4 in table A-1.
> > 
> > Correct. 
> > 
> > > I think that in this case it is reasonable for the answer 
> to signal 
> > > level 4 since it gives similar resolution but hinting that it can 
> > > encode and decode higher bit rate. This will not break 
> > > interoperability and make it simpler for the answerer.
> > 
> > I don't think this is correct according to either RFC 3984 
> or the bis. 
> > As you said earlier, it is allowed to signal level 3.1, and to use 
> > those max-* parameters to indicate that the device has 
> higher than 3.1 
> > capability in a particular aspect, but not the other way 
> round. If you 
> > signal level 4, there is no way to tell which aspect of the 
> capability 
> > is lower than level 4. This is simply not what the spec 
> says. If you 
> > think this way should be supported, you must propose it and make it 
> > said in the spec.
> > 
> > BR, YK
> > 
> > > 
> > > Roni
> > > 
> On Behalf 
> > > Of Ye-Kui Wang
> > > simply cannot encode above level 1.3. "
> > > 
> > > profile-level-id, I am just saying that you need to change the 
> > > semantics. In addition, if the encoding/sending 
> capability and the 
> > > decoding/receiving capability is different, both 
> capabiilties should 
> > > be expressed. One way is to use different direction 
> attributes (and 
> > > separate SDP), which was considered not perfect. The 
> other way is, 
> > > as I mentioned earlier, to use two parameters, one for each.
> > > 
> > > BR, YK
> > > 
> > > > > You asked about sending at "whatever high level the 
> answer may 
> > > > > include".
> > > > > >> >> >> Offerer can send:     A              B       
>         C
> > > > > >> >> >> Answerer can send:    A*             B       
>         B