Subject: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-00.txt

From: [email-masked]
Date: Mon, 6 Oct 2008 06:15:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title           : RTP Payload Format for H.264 Video
	Author(s)       : Y. Wang, et al.
	Filename        : draft-ietf-avt-rtp-rfc3984bis-00.txt
	Pages           : 108
	Date            : 2008-10-06

This memo describes an RTP Payload format for the ITU-T 
Recommendation H.264 video codec and the technically identical 

 ISO/IEC International Standard 14496-10 video codec.  The RTP payload 
format allows for packetization of one or more Network Abstraction 
Layer Units (NALUs), produced by an H.264 video encoder, in each RTP 
payload.  The payload format has wide applicability, as it supports 
applications from simple low bit-rate conversational usage, to 
Internet video streaming with interleaved transmission, to high bit-
rate video-on-demand. 

This memo intends to obsolete RFC 3984.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-rfc3984bis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Mon, 6 Oct 2008 17:42:04 +0300

Technical changes compared to draft-wang-avt-rfc3984bis-01.txt are
listed in the end of the draft. I hereby also copy them for convenience.

-	Changed that reserved NAL unit types MUST be ignored to SHOULD
be ignored in section 5.4. 
-	 (Could be considered as an editorial change as well) In section
8.1, updated the semantics of profile-level-id, especially related to
constraint_set3_flag, signaling of level 1b, Constrained Baseline
profile, and equivalent combinations of profile_idc and profile-iop.  
-	In section 8.1, added 7 new optional media type parameters:
max-smbps, sprop-level-parameter-sets, sar, esar, sprop-ssrc, and
rfc3984-compatible.
-	In section 8.1, updated the semantics of sprop-parameter-sets.
-	In section 8.1, added back parameter-add which is in RFC 3984.
And added that the use of parameter-add is deprecated.
-	In section 8.2.2, the usage of media type parameters with the
SDP offer/answer model has been updated. For example, the parameter
rfc3984-compatible is now part of the media format configuration. Level
downgrade is better clarified. Use of sprop-parameter-sets or
sprop-level-parameter-sets for out-of-band transporting of parameter
sets is explained in more details. 
-	In section 8.4, updated the text such that both out-of-band and
in-band parameter sets transports are possible but neither is
recommended. Clarified that in some scenarios in-band transport is
desired. 
-	Added section 8.5 (informative) discussing decoder refresh point
procedure in case some parameter sets are lost in in-band transport. 

BR, YK

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext 
>[email-masked]
>Sent: 06 October, 2008 16:15
>To: [email-masked]
>Cc: [email-masked]
>Subject: I-D Action:draft-ietf-avt-rtp-rfc3984bis-00.txt 
>
> ISO/IEC International Standard 14496-10 video codec.  The RTP 
>payload format allows for packetization of one or more Network 
>Abstraction Layer Units (NALUs), produced by an H.264 video 
>encoder, in each RTP payload.  The payload format has wide 
>applicability, as it supports applications from simple low 
>bit-rate conversational usage, to Internet video streaming 
>with interleaved transmission, to high bit- rate video-on-demand. 
>
>Below is the data which will enable a MIME compliant mail 
>reader implementation to automatically retrieve the ASCII 
>version of the Internet-Draft.
>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 06 Oct 2008 23:05:06 -0400

>listed in the end of the draft. I hereby also copy them for convenience.

Sorry; my response isn't in time to beat the publication of the draft
revision. 

>procedure in case some parameter sets are lost in in-band transport. 

Several places I see items that are 'reserved' bits, NAL types, etc have
moved from "you MUST ignore" to "you SHOULD ignore".  Is there a reason for
this?  If an RFC 3984bis-compliant receiver doesn't ignore an R bit, but
instead bitches about it, throws away the packet, etc, then it's harder for
a future extension to make use of the R bit.  Similarly, in 8.1, it says
"The receiver SHOULD ignore any unspecified parameter" now instead of MUST.

There's a mix of "de-packetization" and "decapsulation" (see 7.0 for an
example).  Note that "decapsulation" isn't a word in any dictionary I could
find.  (This dates back to RFC 3984.)

8.1 (profile-level-id): the word "lowest" was inserted before level:
"and the lowest level that a decoder has to support in order to comply with
15.1 when it decodes the stream."  Shouldn't that be "highest", not
"lowest"?

sprop-parameter-sets:
"There may be zero of one instance of sprop-level-parameter-sets" - should
be sprop-parameter-sets.

"When the sprop-level-parameter-sets parameter is present,
sprop-parameter-sets MUST NOT be present."  I wouldn't choose that, but I
would say that if both are present, they both must have the same parameter
set for the default level.

sprop-level-parameter-sets:
----------------------------
You need to define how the "three-byte field"s are encoded (similar to
profile-level-id).

"efficient level down-gradable SDP offer/answer and out-of-band" -> "efficient level
downgrade in SDP offer/answer with out-of-band"

"and the level indicated by the parameter sets is the same as the level
indicated by profile-level-id."  I think this is wrong (cut-and-paste?)
Should be gone, or something like "and the level ...is less than or equal
to the level indicated by profile-level-id".

"When rfc3984-compatible is equal to 1 or sprop-parameter-sets is present,
sprop-level-parameter-sets MUST NOT be present."  Why?  An RFC
3984-compatible implementation should (must, really) ignore this parameter.
(Ditto other "new" parameters.)

"There MAY be zero or one or more than one instance of
"sprop-level-parameter-sets" present." Why allow more than one?  It adds
parsing and processing complexity, and is not normally done in other
codec SDP specs.

Various places (mostly/all in 8.3)
The text states in a number of places "this only needs one round of
offer/answer", and similar wordings.  These should probably all be
eliminated, since none say "this needs two rounds", and if it did, it would
probably be wrong.  They just confuse the issue.  The one case that says 
"this would be used in a second round of offer/answer" (in 8.2.2) might
want to be reworded to say "future offer/answer rounds" (or whatever the 
'standard' word for "rounds" is in the offer/answer RFC).

-- 
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: <[email-masked]>
Date: Tue, 7 Oct 2008 14:06:45 +0300

Thanks for your comments!

>"The receiver SHOULD ignore any unspecified parameter" now 

"MUST" means that you cannot use it anyway. "SHOULD" means that you may
use it if you can and if you want. The reason of taking "SHOULD" was to
give a flexibility to implementations that are capabable of using the
reserved values that are specified by a future extension. For example,
an RFC 3984 implementation may be slightly modified to support some of
the new extensions. The intention was not to allow existing
implementations to make arbitrary use of the reserved bits. However, it
seems not easy to say this, as we cannot say that only what will be
specified by a future extension are allowed, as it is not known what
will be specified in the future. OK, changed to "MUST" (at three
places). 

>find.  (This dates back to RFC 3984.)

OK, replaced decapsulation with de-packetization (at two places). 

>15.1 when it decodes the stream."  Shouldn't that be "highest", not

The "lowest" is correct. The decoder is free to support higher levels,
but the minimum requirement is the one indicated by profile-level-id
(when used to indicated stream property). Note that the "highest" is
used when profile-level-id is used to indicated receiver capability
(meaning that you can offer me any lower or equal level). 

>sprop-level-parameter-sets" - should

Thanks. Corrected.

>set for the default level.

I guess you meant that all parameter sets contained in both
sprop-parameter-sets and sprop-level-parameter-sets indicate the same
level. However, in this case, what is the benefit by using both?

BTW, is "the default level" the level indicated by profile-level-id? 

>sprop-level-parameter-sets:

OK. 

>downgrade in SDP offer/answer with out-of-band"

OK. 

>to the level indicated by profile-level-id".

The intention was to require that all parameter sets in one media type
parameter (sprop-parameter-sets or sprop-level-parameter-sets) indicate
only one level. So you think we should allow parameter sets of different
levels in one instance of sprop-parameter-sets or
sprop-level-parameter-sets?

>(Ditto other "new" parameters.)

If sprop-level-parameter-sets is in use and it is ignored, then the
needed parameter sets may be ignored, and the stream cannot be decoded.

>parsing and processing complexity, and is not normally done in other

This is due to the intention require that all parameter sets in one
instance of sprop-level-parameter-sets indicate only one level. If we
allow for parameter sets contained in one instance of
sprop-level-parameter-sets to indicate more than one level, then I don't
see why we would need this new parameter. We can simply use only the
existing sprop-parameter-sets and allow it to contain parameter sets of
more than one level, and recommend that non-required parameter sets
(i.e. those associated with a higher level than what is agreed by the
offerer and the answerer) to be discarded. As the three bytes for
profile-level-id are in the beginning of a sequence parameter set, it is
easy to figure out which sequence parameter sets are needed, but it is
not easy to figure out which picture parameter sets are needed.

>'standard' word for "rounds" is in the offer/answer RFC).

OK, will change this when working on the SDP examples. 

BR, YK

---

From: Randell Jesup <[email-masked]>
Date: Wed, 08 Oct 2008 01:03:51 -0400

<[email-masked]> writes:
>>moved from "you MUST ignore" to "you SHOULD ignore".  Is there a reason
>>for this?  If an RFC 3984bis-compliant receiver doesn't ignore an R bit,
>>but instead bitches about it, throws away the packet, etc, then it's
>>harder for a future extension to make use of the R bit.  Similarly, in
>>8.1, it says "The receiver SHOULD ignore any unspecified parameter" now
>>instead of MUST.
>>
>

In general, "MUST ignore" is how reserved bits/values are handled so
a future expansion can use them.  The idea is that a compliant 
implementation can be guaranteed not to be broken when talking to 
an implementation implementing a new version (extension or a bis version).
If it's "SHOULD ignore", then effectively you can never use them for
future versions.

Note that this means that a Blah-bis implementation may be strictly
non-compliant with Blah, since it uses those bits.  That's ok, so long as
Blah-bis is backward-compatible with Blah.

>OK, replaced decapsulation with de-packetization (at two places). 

Careful - there are variants (decapsulated, etc).

>>"and the lowest level that a decoder has to support in order to comply
>>with 15.1 when it decodes the stream."  Shouldn't that be "highest", not
>>"lowest"?
>>
>

Ok - I was reading fast and it's dense.

>>would say that if both are present, they both must have the same
>>parameter set for the default level.
>

No - sprop-parameter-sets can only supply the parameter-sets for a single
level (matching profile-level-id).  sprop-level-parameter-sets can supply
parameter sets for a series of possible level-downgrades.  What I was
saying was:

a) There's no need for them to be exclusive, and in fact it will reduce
interoperability (you have to guess about which the recipient will support).

b) If therefore you have both, there needs to be a requirement that if
the profile-level-id value for sprop-parameter-sets also appears in
sprop-level-parameter-sets, then the parameter sets for that
profile-level-id value will need to match.

>BTW, is "the default level" the level indicated by profile-level-id? 

Yes.

>sprop-level-parameter-sets?

One of the main reasons for sprop-level-parameter-sets was to provide
parameter sets for possible level downgrades.

>>"When rfc3984-compatible is equal to 1 or sprop-parameter-sets is
>>present, sprop-level-parameter-sets MUST NOT be present."  Why?  An RFC
>>3984-compatible implementation should (must, really) ignore this
>>parameter.  (Ditto other "new" parameters.)
>

No - if it's ignored, then the normal RFC 3984 rules would apply, which do
not require parameter sets (you are allowed to use inband parameter sets).
Also, if we allow both sprop-parameter-sets and sprop-level-parameter-sets,
then RFC 3984-compatible processing would use sprop-parameter-sets (if
given).

Honestly, I don't see the purpose of rfc3984-compatible at all as a
parameter, unless there's a semantic difference keyed off by it or
a relaxation on a response that's important.

>not easy to figure out which picture parameter sets are needed.

I see the problem.  I think you mis-understood my proposal for 
sprop-level-parameter-sets.  It is meant to allow for specifying parameter
sets for different levels (which otherwise can't be done, as we've
determined on the list).

The idea is that an SDP parser should not have to (and really can't) delve
*into* the parameter sets themselves, and that level-downgrade can be handled
and use out-of-band parameter sets, without a re-INVITE.  It also avoids
the problem of trying to match up picture parameter sets go with which level.

Something like:
   ...profile-level-id=42e01e;sprop-parameter-sets=<paramsets for 3.0>;sprop-level-parameter-sets=42e014:<paramsets for 2.0>:42e00c:<paramsets for 1.2>:42e00b:<paramsets for 1.1>:42e00a:<paramsets for 1.0>

(Note: I used ':' instead of ',' because a comma would lead to an ambiguous
BNF, since <paramsets> has multiple parameter sets in base64 separated by
commas.  We could also use any other non-base64 character, other than ';'.)

---

From: <[email-masked]>
Date: Wed, 8 Oct 2008 11:01:51 +0300

(1) Gone through the document, and made changes like interarrival ->
inter-arrival, decapsulating/decapsulated ->
de-packetizing/de-packetized, deinterleaving -> de-interleaving.

(2) On sprop-parameter-sets and sprop-level-parameter-sets. Got two
missing pieces in my original understanding to what we have agreed
earlier on this. i) Use one instance of sprop-level-parameter-sets
instead of chopping it into multiple instances (each for one level). ii)
Try to make sprop-level-parameter-sets backwards compatible to RFC 3984,
and make use of sprop-parameter-sets for parameter sets of the default
level.

However, the change cannot be fully backwards compatible, as in RFC 3984
sprop-parameter-sets may contain parameter sets of multiple levels.
Therefore, a stream packetized according to RFC 3984 may be
non-conforming to the bis draft.  

(3) The purpose of having rfc3984-compatible is to allow an RFC 3984
fully compatible mode, as RFC 3984 is anyway working for some major use
cases (e.g. when no out-of-band transport of parameter sets is in use).
This means, as you mentioned, that there does need to be a semantic
difference or operatonal difference (e.g. a relaxation or restriction)
difference keyed off by it. I have already included open issues for
studies of what would be those semantic and/or operational differences. 

BR, YK 

>From: ext Randell Jesup [mailto:[email-masked]] 
>Sent: 08 October, 2008 08:04
>To: Wang Ye-Kui (Nokia-NRC/Tampere)
>Cc: [email-masked]
>Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-00.txt
>
>   ...profile-level-id=42e01e;sprop-parameter-sets=<paramsets 
>for 3.0>;sprop-level-parameter-sets=42e014:<paramsets for 
>2.0>:42e00c:<paramsets for 1.2>:42e00b:<paramsets for 
>1.1>:42e00a:<paramsets for 1.0>
>

---

From: Randell Jesup <[email-masked]>
Date: Thu, 09 Oct 2008 13:00:25 -0400

>non-conforming to the bis draft.  

Actually, I think we came to the conclusion (based on your H.264 knowledge)
that sprop-parameter-sets CANNOT legally include values for levels other
than the agreed-on one, since *all* those parameter sets will need to be
fed into the decoder.  That's why sprop-level-parameter-sets was created -
so you can identify the parameter sets for a specific level. (I had
originally assumed sprop-parameter-sets could have multiple levels, which
is theoretically true in rfc 3984 SDP, but apparently I was wrong per the
H.264 spec).  In any case, this is cleaner for out-of-band parameter sets
with level-downgrade.

>studies of what would be those semantic and/or operational differences. 

Again, I don't see any practical use of or need for rfc3984-compatible -
and if I did, I'd strongly suggest we try to work around the problem to
eliminate the need for it.  In some cases you can't avoid something like
that, but I don't think that applies here.

If those "open issues" turn out not to be resolvable without it, ok - but
you do that after you find they're unresolvable.

---

From: "Roni Even" <[email-masked]>
Date: Thu, 9 Oct 2008 19:57:53 +0200

Hi,
Randell's first comment on sprop-parameter-set is right, this is just the
out of band sending of the parameter sets, the profile-level-id parameter is
where we made the change from RFC3984 clarifying the point that levels are
down-gradable which was already in practice by some implemenations.
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Randell Jesup
Sent: Thursday, October 09, 2008 7:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-00.txt

-- 
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: <[email-masked]>
Date: Thu, 9 Oct 2008 22:22:13 +0300

See inline, please.

>From: ext Roni Even [mailto:[email-masked]] 
>Sent: 09 October, 2008 20:58
>To: 'Randell Jesup'; Wang Ye-Kui (Nokia-NRC/Tampere)
>Cc: [email-masked]
>Subject: RE: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-00.txt
>
>Hi,

Agreed. That's also my understanding.

>H.264 spec).  In any case, this is cleaner for out-of-band 

After thinking more carefully and checking with some other H.264/AVC
experts, it turned out that my understanding regarding this one was
wrong. Sorry for the confusion. The relevant text, in subclause
7.4.1.2.2 of H.264/AVC, is copied below for convenience. The wording of
"an otherwise-conforming bitstream" is not deadly clear, but it was
concluded that a sequence parameter set may be associated with a
different profile or level than the one of the active sequence parameter
set. 

"All constraints that are expressed on the relationship between the
values of the syntax elements (and the values of variables derived from
those syntax elements) in sequence parameter sets and picture parameter
sets and other syntax elements are expressions of constraints that apply
only to the active sequence parameter set and the active picture
parameter set. If any sequence parameter set RBSP is present that is not
activated in the bitstream, its syntax elements shall have values that
would conform to the specified constraints if it were activated by
reference in an otherwise-conforming bitstream. If any picture parameter
set RBSP is present that is not ever activated in the bitstream, its
syntax elements shall have values that would conform to the specified
constraints if it were activated by reference in an otherwise-conforming
bitstream."

However, I still think having sprop-level-parameter-sets is good to
allow efficient level downgrade in offer/answer. Without
sprop-level-parameter-sets , we have two alternatives. In both
alternatives, the offer includes parameter sets for different levels in
sprop-parameter-sets. With the first alternative, after negotiation, the
parameter sets associated with levels different than the agreed level
are fed to the decoder even though they are never used. This essentially
restricts encoding optimization as less parameter sets can be really
used. The second alternative is that, after negotiation, the answerer
discards all parameter sets not assoicated with the agreed level - but
this requires that the answerer needs to parse deeper into the parameter
set NAL units to figure out which ones are to be discarded. 

>you do that after you find they're unresolvable.

If we can make all the changes (except for clear bug fixes) fully
backwards compatible, then yes, we don't need this parameter. However,
we did have made a few non-backwards-compatible changes. For example, we
have removed the restriction that sprop-parameter-sets in an SDP answer
shall be equal to or a superset of that in the offer, and this
restriction is related to parameter-add, which is now present but the
use is deprecated. Another example is when we use both
sprop-parameter-sets and sprop-level-parameter-sets at the same time.
Can we make these two fully backwards compatible or can they be
tolerated (as on-backwards-compatible)?

BR, YK

---

From: Randell Jesup <[email-masked]>
Date: Fri, 10 Oct 2008 21:44:01 -0400

<[email-masked]> writes:
>>Actually, I think we came to the conclusion (based on your H.264
>>knowledge) that sprop-parameter-sets CANNOT legally include values for
>>levels other than the agreed-on one, since *all* those parameter sets
>>will need to be fed into the decoder.  That's why
>>sprop-level-parameter-sets was created - so you can identify the
>>parameter sets for a specific level. (I had originally assumed
>>sprop-parameter-sets could have multiple levels, which is theoretically
>>true in rfc 3984 SDP, but apparently I was wrong per the H.264 spec).  In
>>any case, this is cleaner for out-of-band parameter sets with
>>level-downgrade.
>>
>

Ok.  I think conceptually it's simpler to mark out the parameter sets for a
level directly (using sprop-level-parameter-sets), and avoid having to
install a large number of sets when most can't be used.  (In theory,
different levels might be able to share Picture Parameter Sets, but it's
not worth the problem I think.)

>use is deprecated.

Ok.  Those are certainly changes that are in theory incompatible.

Here's a question: is there any actual implementation who actually would be
broken by not copying the offered parameter set in the answer, or by
not supporting parameter-add=0?

We could also require (in -bis) that if you put sprop-parameter-sets in,
you must also put sprop-level-parameter-sets in.  It does have the downside
of making it less obvious, but one could forget to add rfc3984-compatible
too.  The nice thing here is that an rfc3984-only answerer will just ignore
sprop-level-parameter-sets.

If we do use rfc3984-compatible, I'll want to read over the usage again

>Another example is when we use both sprop-parameter-sets and
>sprop-level-parameter-sets at the same time.  Can we make these two fully
>backwards compatible or can they be tolerated (as
>on-backwards-compatible)?

Oh, you certainly could have both, and it shouldn't cause any problem.  The
only stipulation I'd make is that *if* both contain parameter sets for the
profile-level-id value (the highest level supported), they have the same
parameter sets for that level-id.

---

From: "Roni Even" <[email-masked]>
Date: Sun, 12 Oct 2008 10:01:18 +0200

Hi,
I think that the issue of sprop-parameter-set in backward compatibility is
tied to the symmetry in profile-level-id. Having the same set in the offer
and answer make sense if symmetry is mandatory. In the bis draft we took out
the requirement for symmetry on the level assuming that there are no real
backward compatibility issues.
I assume that a 3984 receiver may answer symmetry with the same parameter
sets or if it ignores the required symmetry, that did not make sense on the
level, then I assume that it may also answer with a different parameter
sets. 

I do not see any value in rfc3984-compatible parameter, it does not help an
RFC3984 implementation since it does not understand this parameter and would
just ignore it.

Roni

---

From: <[email-masked]>
Date: Mon, 13 Oct 2008 11:38:33 +0300

My comments to both Roni's and Randell's comments are interspersed below
inline.

>Sent: 12 October, 2008 11:01

I think we can consider that the symmetry requirement on
profile-level-id does not exist in RFC 3984, as there is text (even
buried deeply) saying that level downgrade is possible. Therefore,
making it clear in the bis draft that level downgrade is possible should
be considered as an editorial clarification to RFC 3984. 

>RFC3984 implementation since it does not understand this 

Yes it does not help RFC 3984 implementations, but it does help for the
future bis draft implementations to understand whether the other side
understands the bis extensions. For example, an offerer can probe the
answerer by including rfc3984-compatible equal to 0, and if the answer
does not include rfc3984-compatible, then the offerer knows that the
answerer does not understand the bis extensions and should not rely on
bis extensions. Magnus, maybe you have somethinhg to say on this (as the
original proponent)?

>install a large number of sets when most can't be used.  

Good - so this point (of having sprop-level-parameter-sets) is agreed.

> (In theory,

This is actually not possible, as each sequence parameter set can only
be tied to one level, while each picture parameter set can only be tied
to one sequence parameter set. Therefore, the solution is clean :-)

>not supporting parameter-add=0?

I GUESS no. 

>sprop-level-parameter-sets.

Assume that level downgrade is possible, and we allow to use both
sprop-parameter-sets and sprop-level-parameter-sets together, and we use
only out-of-band transport of parameter sets. 

For a legacy 3984 receiver, as it ignores sprop-level-parameter-sets,
then sprop-parameter-sets should contain basically all parameter sets
included in sprop-level-parameter-sets. For a -bis receiver, it only
needs to use sprop-level-parameter-sets. Therefore, why would we use
both sprop-parameter-sets and sprop-level-parameter-sets?

>If we do use rfc3984-compatible, I'll want to read over the usage again

Fair enough. Above (in response to Roni) is one usage. Other usages we
can only have clear text after identifing what operations are possible
per the -bis draft but not per 3984. 

>parameter sets for that level-id.

See above. We seem have different ways of operations in mind (e.g. your
were probably assuming that level downgrade OR out-of-band parameter
sets transport is not used by the 3984 receivers).

BR, YK

---

From: "Roni Even" <[email-masked]>
Date: Mon, 13 Oct 2008 10:58:29 +0200

Inline
Roni
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 13, 2008 10:39 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-00.txt

RE: - I think that there are two points to consider

1. The support for new parameters can be implied from the answer
2. The signaling of support for bis extension does not guarantee support for
all new parameters since they are optional. So the offerer cannot assume
that the other side supports them

---

From: <[email-masked]>
Date: Mon, 13 Oct 2008 12:42:46 +0300

>1. The support for new parameters can be implied from the answer

Good point. If the issue is only about new parameters, then there is no
need of the rfc3984-compatible parameter. However, we still have one
point regarding the restriction in RFC 3984, on that the answer MUST
include all parameter sets existing in the offer, which has been relaxed
in the -bis draft. We need to identify whether there are other
operations that do not need the use of any new parameters and that are
not backwards compatible. 

>that the other side supports them

My understanding is different. For example, for the existing optional
parameters defined in RFC 3984, all agents implementing RFC 3984 must
understand and support all the optional parameters, while the use of any
optional parameters is optional. Otherwise, how does one know whether an
optional parameter is supported or not?

BR, YK

---

From: "Roni Even" <[email-masked]>
Date: Mon, 13 Oct 2008 13:53:05 +0200

YK,
Inline
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 13, 2008 11:43 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-00.txt

RE: In the example you gave the rfc3984-compatible will not help you.
If the receiver does not support bis draft he will responds with the same
set(hopefully-I am not sure what will happen with terminals doing in-band or
supporting level downgrade)
If the receiver support the bis draft it will respond either with the same
or different set.
So why do you need the parameter

RE: Optional means that you need to understand but not to support. That is
why you can reject parameters in the answer.

BR, YK

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 Oct 2008 15:15:55 +0200

Hi,

When it comes to parameter design, start thinking about what
requirements you really have on the information you need to carry. Then
we can figure out how to do the actual design. If one needs to have a
flag parameter or if simply removing or including in a response a
parameter is sufficient semantics.

Cheers

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Mon, 13 Oct 2008 17:02:07 -0400

<[email-masked]> writes:
>>Ok.  I think conceptually it's simpler to mark out the parameter sets for
>>a level directly (using sprop-level-parameter-sets), and avoid having to
>>(In theory, different levels might be able to share Picture Parameter
>>Sets, but it's not worth the problem I think.)
>

Ok, good.

>>you must also put sprop-level-parameter-sets in.  It does have the
>>downside of making it less obvious, but one could forget to add
>>rfc3984-compatible too.  The nice thing here is that an rfc3984-only
>>answerer will just ignore sprop-level-parameter-sets.
>

So, where did we end up on sprop-parameter-sets: (after much discussion) it
was stated that we couldn't really include parameter sets for possible
level downgrades in sprop-parameter-sets.  I take it from a more recent
email from you that this isn't actually the case - you can include multiple
levels in sprop-parameter-sets.  The downside of including them is that
you'd chew up a lot of parameter-set slots (and there's a limit on the
number - 8?), and you need to keep at least one set free to allow for 
in-band updates to parameter sets.  Conceptually,
sprop-level-parameter-sets is nicer.

The issue remaining is how to make an offer understandable and usable by
an rfc 3984 answerer.  

Options:
1) Duplicate all parameter sets in sprop-parameter-sets and
   sprop-level-parameter-sets.  Downsides: wastes space, wastes parameter
   slots. Upsides: allows out-of-band parameter sets with level downgrade
   for an rfc 3984 answerer.
2) Duplicate only the parameter sets for profile-level-id (highest level)
   in sprop-parameter-sets; put sets for all possible/suggested downgrades
   in sprop-level-parameter-sets.  Downsides: requires in-band parameter
   sets for level downgrade with rfc 3984 answerer.  Upside: allows
   out-of-band parameter sets with rfc 3984 for the no-downgrade case.
   Smaller and doesn't waste slots.
3) Include only sprop-level-parameter-sets; do not include
   sprop-parameter-sets.  This implies that with an RFC 3984 answerer the
   exchange will fall back to in-band parameter sets.  Upside: even
   smaller.  Downside: relies on in-band parameter sets in all cases when
   talking to an rfc 3984 answerer.
4) Use only sprop-parameter-sets; include parameter sets for all downgrade
   options.  Upside: smallest with out-of-band parameter sets, least change
   from rfc 3984.  Downside: limited parameter set indexes, no easy way for
   answerer to choose a "preferred" level to downgrade to.

>>>sprop-level-parameter-sets at the same time.  Can we make these two
>>>fully backwards compatible or can they be tolerated (as
>>Oh, you certainly could have both, and it shouldn't cause any problem.
>>The only stipulation I'd make is that *if* both contain parameter sets
>>for the profile-level-id value (the highest level supported), they have
>>the same parameter sets for that level-id.
>

I'm not sure what you think I was thinking of. :-)

My thoughts are to allow out-of-band parameter sets with RFC3984 answerers,
and make it possible to do level downgrade combined with out-of-band
parameter sets using sprop-level-parameter-sets.  In theory, it now seems
we could put them all in sprop-parameter-sets (or at least several), but
there's no easy way without parsing the internals of all of them for the
answerer to know which levels the offerer put into the out-of-band
parameter sets.  That's why I like sprop-level-parameter-sets.

---

From: <[email-masked]>
Date: Mon, 20 Oct 2008 13:41:19 +0300

I think we now have a common understanding of the entire issue, but our
preferences may still differ. Here is a proposal, please let me know
whether it is fine with you, and if not, what do you prefer. 

- We specify both sprop-parameter-sets and sprop-level-parameter-sets.

- In an offer, when sprop-level-parameter-sets is present,
sprop-parameter-sets must be present. An offer may also contain only
sprop-parameter-sets. In an answer, sprop-parameter-sets and
sprop-level-parameter-sets must not be both present.

- sprop-parameter-sets can only contain parameter sets of the default
level (the one in profile-level-id). ***Note that this point is not
backwards compatible to RFC 3984, wherein sprop-parameter-sets may
contain parameter sets for any levels.***

- sprop-level-parameter-sets can only contain parameter sets of one or
more levels lower than the default level. 

- If the default level is accepted by the answerer, the parameter sets
in sprop-parameter-sets must be used, and the answerer must ignore
sprop-level-parameter-sets even it understands
sprop-level-parameter-sets. 

- If a lower level is accepted, the answerer must discard
sprop-parameter-sets. If the answerer understands
sprop-level-parameter-sets and there are parameter sets therein for the
accepted level, those parameter sets must be used and other parameter
sets in sprop-level-parameter-sets must be discarded; otherwise, in-band
parameter sets transport must be used.

- After a level is accepted, the answerer may include one of
sprop-parameter-sets and sprop-level-parameter-sets, depending on the
accepted level. The included sprop-parameter-sets or
sprop-level-parameter-sets is independent of the offer. When the
accepted level is the default level, only sprop-parameter-sets may be
included in the answer. When the accepted level is a level lower than
the default level, only sprop-level-parameter-sets may be included in
the answer, and sprop-level-parameter-sets must not contain parameter
sets for any level other than the accepted level. ***Note that this
entire point is not backwards compatible to RFC 3984, related to
parameter-add.***

- When a level is accepted by the answerer, the following applies. If
the answerer includes sprop-parameter-sets or
sprop-level-parameter-sets, the parameter sets therein must be used.
Otherwise, in-band parameter sets transport must be used. 

Note also that, the use of out-of-band parameter sets transport, using
sprop-parameter-sets and/or sprop-level-parameter-sets, does not prevent
the use of in-band transport of additional parameter sets. Application
standards may further specify that only in-band or out-of-band parameter
sets transport may be used. For example, 3GPP PSS mandates the use of
only out-of-band parameter sets transport. 

BR, YK 

>Sent: 14 October, 2008 00:02
>Cc: [email-masked]; [email-masked]; 
>[email-masked]