Subject: Re: [AVT] WGLC on RFC3984bis - comments

From: "Roni Even" <[email-masked]>
Date: Wed, 14 Jan 2009 11:54:29 +0200

Hi 
I reviewed RFC3984bis and have some comments and nits

Roni Even

Comments

1.	Section 1 - I suggest changing the first sentence to "This sentence
obsoletes RFC3984". I  also think that this paragraph should be moved after
section 1.1 since this is not the major purpose of the document.
2.	In section 4.1 the last sentence for default sub-profile and default
level gives some normative text about offer answer. Maybe it should  be
taken out since it is not part of the definition.
3.	The last informative note in section 5.1. I thought that the inter
arrival jitter is based on the transmit time which is the RTP timestamp so I
am not clear why it is not correct for H.264.
4.	In section 5.3 in the paragraph "An H.264 encoder SHOULD set the
value of NRI for coded slice and coded slice data partition NAL units of
redundant coded reference  pictures equal to 01 (in binary format)."  Is
this the job of the H.264 encoder in which case maybe this should be part of
H.264 specification.
5.	In section 7.3  first bullet  "If a lost DPA is found, a gateway may
decide not to send the corresponding coded slice data  partitions B and C,
as their information is meaningless for H.264 decoders." Is this the right
behavior, what if the receiver uses retransmit or some FEC to correct such
loss.
6.	In section 8.2.2 when discussing level downgrade the first bullet
says that the parameter sets must be ignored. Does this mean that the
parameters sets will be in band or does it mean the there should be a new
offer in a re-invite for the offerer parameter sets.  There is an example is
section 8.3 where the offer is with level 3 and the answer is level 2,
downgrading the level. The text there says that in band parameters sets must
be used, why not a second offer.
7.	The IANA consideration is that this document update RFC3984 for the
h264 payload subtype name.

Nits
1.	Table of content does not have the page numbers
2.	In section 5.2 in the paragraph starting with Table 1 change
"directly used a packet" to "directly used in a packet"
3.	In section 7 first paragraph change "the output is the same meaning"
to "the same output means"
4.	The last paragraph of 7.2.1 repeats the previous paragraph and can
be deleted.
5.	In section 7.2.2 third bullet you have "type" twice.
6.	Maybe you YK should update his email address.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 15 Jan 2009 10:34:10 -0500

Hi Roni,

Thanks for your comments. See my responses in line below.

BR, YK

---------- Forwarded message ----------
From: Roni Even <[email-masked]>
Date: Wed, Jan 14, 2009 at 4:54 AM
Subject: Re: [AVT] WGLC on RFC3984bis - comments
To: IETF AVT WG <[email-masked]>

Hi

Roni Even

Comments

[Ye-Kui Wang] I also made the same change to the sentence in the abstract.
To improve the paragraph structure, I moved the first paragraph in section
1.1 to the beginning of section 1.

[Ye-Kui Wang] Done. I have made an improvement to the definition of default
level by adding how the default level is indicated by profile-level-id.

[Ye-Kui Wang] Here is my understanding. Jitter should be calculated
according to the transmit times packets, while RTP timestamp indicates
presentation time. Only when the transmission order is the same as the
presentation order, then directly jitter calculated directly based on RTP
timestamps is correct. However, in many cases, the transmission order is not
the same as the presentation order. One example is interleaved transmission
of coded data units (assuming that the bitstream order is the same as
presentation order). Another example is when the bitstream order itself is
different from presentation order, as allowed in H.264/AVC, (assuming that
the transmission order is the same as bitstream order). Therefore, not only
just for H.264/AVC, but for any codec when interleaved transmited or for
which the bitstream order may be different from presentation order, jitter
calculated directly based on RTP timestamps is not correct. Maybe there
should be an an update to RFC 3550 in this aspect?

[Ye-Kui Wang] No, the H.264/AVC spec is silent about this, as therein the
only difference is whether this two-bit field is equal to 0  or not.

[Ye-Kui Wang] Good point. But I think the sentence is fine with this point,
as it uses "may". In case a gateway knows that something like retransmission
or FEC is in use it may take another approach to handle data partition NAL
units.

6.      In section 8.2.2 when discussing level downgrade the first bullet
says that the parameter sets must be ignored. 

[Ye-Kui Wang] The bullet says that the parameter sets included in
"sprop-parameter-sets" must be ignored, but the following text further says
that it may use parameter sets included in "sprop-level-parameter-sets".

Does this mean that the

[Ye-Kui Wang] A new offer in a re-invite is always possible. The normative
text allows this. And the example only demonstrates the case when there is
neither "sprop-parameter-sets" nor "sprop-level-parameter-sets". 

[Ye-Kui Wang] Corrected. I changed the phrasing to "The H264 media subtype
name specified by RFC 3984 should be updated as defined in section 8.1 of
this memo.".

Nits

[Ye-Kui Wang] This is strange - it always gives me page numbers for the TOC
whenever I opened draft-ietf-avt-rtp-rfc3984bis-02.txt using whatever
editing software. What are you using to view the file? Does anyone else have
the same problem? 

[Ye-Kui Wang] Corrected "directly used a packet payload" to "directly used
as a packet payload".

[Ye-Kui Wang] Done.

[Ye-Kui Wang] Not really. The peer text in the previous graph is for SDP
offer/answer, while this paragraph is for declarative usage. We can either
keep it as is or merge it to the previous graph, but make the usage for both
cases clear. I tend to keep it as is.

[Ye-Kui Wang] Removed one.

[Ye-Kui Wang] Updated.

---

From: "Roni Even" <[email-masked]>
Date: Thu, 15 Jan 2009 18:26:14 +0200

YK,

The content page number look in
http://tools.ietf.org/wg/avt/draft-ietf-avt-rtp-rfc3984bis/   

Both html and txt version do not have page numbers.

See inline 

From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Thursday, January 15, 2009 5:34 PM
To: 'Roni Even'
Cc: 'IETF AVT WG'
Subject: RE: [AVT] WGLC on RFC3984bis - comments

Hi Roni,

BR, YK

---------- Forwarded message ----------
From: Roni Even <[email-masked]>
Date: Wed, Jan 14, 2009 at 4:54 AM
Subject: Re: [AVT] WGLC on RFC3984bis - comments
To: IETF AVT WG <[email-masked]>

Hi

Roni Even

Comments

 

[RE] - So it is not the H.264 encoder but the RTP encoder that does it.

[RE] maybe you should have some text about retransmit and FEC

Does this mean that the

[RE] the example is section 8.3 says that inband must be used so maybe you
can relax the text in the example.

Nits

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 16 Jan 2009 11:08:12 -0500

Roni,

See inline, please. 

BR, YK

[Ye-Kui Wang] Got it - the page numbers there are all "3". Not sure how it
came like this, but I will make sure page numbers are correct in the next
version.

[Ye-Kui Wang] Correct.

[Ye-Kui Wang] OK. I changed the sentence to "If a lost DPA is found, after
taking into account possible retransmission and FEC, a gateway may .".

Does this mean that the

[Ye-Kui Wang] I am not sure I can make a change herein that is correct
aligned with my own understanding, as explained in the following. After one
offer/answer, the flow starts regardless of whether there will be a
RE-INVITE. Therefore, it is correct that in-band transport of parameter sets
must be used when no out-of-band transport is in use as part of the
offer/answer. A RE-INVITE initiates a new offer/answer process, for which
the process described in the draft is simply repeated. Therefore, if you are
still not happy the current text, could you please try to suggest a change
(you are a co-author of the draft anyway :-)?

---

From: Colin Perkins <[email-masked]>
Date: Fri, 16 Jan 2009 23:52:28 +0000

On 17 Dec 2008, at 02:12, Tom Taylor wrote:
> I have consulted with Roni, who pointed out that other SDOs have a  
> dependency on the subject drafts. We are therefore announcing a  
> Working Group Last Call on the following documents:
>
> draft-ietf-avt-rfc3984bis-02.txt, RTP Payload Format for H.264 Video
>
> draft-ietf-avt-svc-16.txt, RTP Payload Format for SVC Video

It's been several months since I read the SVC payload format, and I'm  
pleased to see it's improved greatly since then. The current draft is  
pretty good, although I do have some comments:

As Roni mentioned, the abstract is too long. I suggest keeping the  
first and last sentences, and deleting the rest.

In Section 1, on page 5, the informative note suggests that a MANE  
can convert a media stream from SVC to H.264/AVC "simply by  
eliminating RTP packets", provided the stream is structured in a  
particular way. This is not correct: the MANE is an RTP translator,  
and so must follow the rules defined in Section 7 of RFC 3550, which  
mandate rewriting RTCP to match changes made to the RTP stream.

Similarly, RFC 3550 section 7 should be referenced from the last  
bullet point of Section 1.2.1, and from section 3.1.2 at the top of  
page 21.

Editorial: Section 4.7.1, bottom of page 35, do you mean figure 2,  
rather than figure 3?

The discussion of NI-T and NI-TC packetization rules in section 5.2.1  
is unclear in places. In particular:

- The paragraph after the bullet list on page 49 (starting "If a  
packet must be inserted for satisfying...") could be clarified. RTP  
packets don't directly contain an NTP timestamp. It might be better  
phrased as "...the inserted packet must have an RTP timestamp that  
maps to the same wall-clock (NTP-format) time as the RTP timestamp of  
a packet of the access unit..."

- The discussion at the end of page 50 and start of page 51, showing  
how to generate the timestamp for the inserted packet looks correct,  
but I'm not sure it's helpful. The calculation seems to be that which  
a receiver would do to estimate the timestamp. A sender would, on the  
other hand, know the exact mapping from wall-clock (NTP) time to RTP  
time, and so doesn't need to calculate the correct offset from the  
RTCP SR packets.

- It would be helpful, I think, if section 5.2.1 explained that the  
mapping between wall-clock (NTP format) timestamps and RTP timestamps  
is conveyed from sender to receiver using RTCP SR packets, or the RTP  
proposed header extensions.

Following on from this, the informative note in section 6.2.1 (page  
54) would perhaps be clearer written as "The mapping between RTP and  
NTP format timestamps is conveyed in RTCP SR packets. In addition,  
the mechanisms for faster media timestamp synchronisation discussed  
in [...] may be used to speed to acquisition of the RTP-to-wall-clock  
mapping".

Also in section 6.2.1, second bullet point on page 55, clarify that  
the "media timestamp" is the NTP-format timestamp derived from the  
RTP timestamps of the NAL units.

Section 7.2.3 discusses how to signal multi-session transmissions of  
SVC in SDP. RFC 4566 section 5.7 defines an alternative mechanism to  
signal such sessions. Is it legal for that alternative to be used? If  
so, if should be referenced, if not, this draft should explicitly  
prohibit that use.

Section 11.6 disallows "SSRC multiplexing", but the discussion of MST  
in section 1.2.2 seems to allow it. I see no reason to disallow it.

-- 
Colin Perkins
http://csperkins.org/

---

From: Ye-Kui Wang <[email-masked]>
Date: Mon, 26 Jan 2009 18:13:42 -0500

Dear All,

Thanks a lot for your comments to the SVC draft. We are handling them. For
two of the comments, one from Colin and the other from Jonathan, we need
clarifications. 

[Colin]:
> Section 11.6 disallows "SSRC multiplexing", but the 
> discussion of MST in section 1.2.2 seems to allow it. I see 
> no reason to disallow it.

Section 11.6 gives an (informative) explanation why a full support of SSRC
multiplexing, which needs a mapping from SSRC values to layers, is not
provided in the memo. It does not really disallow SSRC multiplexing, but the
current draft as it is does not fully support SSRC multiplexing either. We
have two options. One is to add back the mechanim we had once earlier for
mapping of SSRC values to layers. The other is to clarify better in section
11.6 that a full support of SSRC multiplexing needs a mapping from SSRC
values to layers, but is not specified in the document. Any preference (or
suggestion if you don't like either option)?

[Jonathan]:
> Section 7.2.1 (Mapping of Payload Type Parameters to SDP):  I 
> believe it would be useful to be able to represent 
> sprop-scalability-info and sprop-operation-point-info in the 
> fmtp source attribute as well.  I don't currently see any 
> motivation for including sprop-no-NAL-reordering-required or 
> sprop-avc-ready in the fmtp source attribute, but they might 
> be worth considering.
> 

Do you have any use cases in mind for inclusion of additional parameters to
the fmtp source attribute? We tend to leave the text unchanged (for
simplicity) unless there are compelling use cases.

Best Regards,
Ye-Kui, Thomas, Alex

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Colin Perkins
> Sent: Friday, January 16, 2009 6:52 PM
> To: Tom Taylor
> Cc: IETF AVT WG
> Subject: Re: [AVT] WGLC on RFC3984bis and SVC
> 
> It's been several months since I read the SVC payload format, 
> and I'm pleased to see it's improved greatly since then. The 
> current draft is pretty good, although I do have some comments:
> 
> As Roni mentioned, the abstract is too long. I suggest 
> keeping the first and last sentences, and deleting the rest.
> 
> In Section 1, on page 5, the informative note suggests that a 
> MANE can convert a media stream from SVC to H.264/AVC "simply 
> by eliminating RTP packets", provided the stream is 
> structured in a particular way. This is not correct: the MANE 
> is an RTP translator, and so must follow the rules defined in 
> Section 7 of RFC 3550, which mandate rewriting RTCP to match 
> changes made to the RTP stream.
> 
> Similarly, RFC 3550 section 7 should be referenced from the 
> last bullet point of Section 1.2.1, and from section 3.1.2 at 
> the top of page 21.
> 
> Editorial: Section 4.7.1, bottom of page 35, do you mean 
> figure 2, rather than figure 3?
> 
> The discussion of NI-T and NI-TC packetization rules in 
> section 5.2.1 is unclear in places. In particular:
> 
> - The paragraph after the bullet list on page 49 (starting 
> "If a packet must be inserted for satisfying...") could be 
> clarified. RTP packets don't directly contain an NTP 
> timestamp. It might be better phrased as "...the inserted 
> packet must have an RTP timestamp that maps to the same 
> wall-clock (NTP-format) time as the RTP timestamp of a packet 
> of the access unit..."
> 
> - The discussion at the end of page 50 and start of page 51, 
> showing how to generate the timestamp for the inserted packet 
> looks correct, but I'm not sure it's helpful. The calculation 
> seems to be that which a receiver would do to estimate the 
> timestamp. A sender would, on the other hand, know the exact 
> mapping from wall-clock (NTP) time to RTP time, and so 
> doesn't need to calculate the correct offset from the RTCP SR packets.
> 
> - It would be helpful, I think, if section 5.2.1 explained 
> that the mapping between wall-clock (NTP format) timestamps 
> and RTP timestamps is conveyed from sender to receiver using 
> RTCP SR packets, or the RTP proposed header extensions.
> 
> 54) would perhaps be clearer written as "The mapping between 
> RTP and NTP format timestamps is conveyed in RTCP SR packets. 
> In addition, the mechanisms for faster media timestamp 
> synchronisation discussed in [...] may be used to speed to 
> acquisition of the RTP-to-wall-clock mapping".
> 
> Also in section 6.2.1, second bullet point on page 55, 
> clarify that the "media timestamp" is the NTP-format 
> timestamp derived from the RTP timestamps of the NAL units.
> 
> Section 7.2.3 discusses how to signal multi-session 
> transmissions of SVC in SDP. RFC 4566 section 5.7 defines an 
> alternative mechanism to signal such sessions. Is it legal 
> for that alternative to be used? If so, if should be 
> referenced, if not, this draft should explicitly prohibit that use.
> 
> Section 11.6 disallows "SSRC multiplexing", but the 
> discussion of MST in section 1.2.2 seems to allow it. I see 
> no reason to disallow it.
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 Jan 2009 19:02:58 +0000

On 26 Jan 2009, at 23:13, Ye-Kui Wang wrote:
> Thanks a lot for your comments to the SVC draft. We are handling  
> them. For two of the comments, one from Colin and the other from  
> Jonathan, we need clarifications.
>
> [Colin]:
>> Section 11.6 disallows "SSRC multiplexing", but the discussion of  
>> MST in section 1.2.2 seems to allow it. I see  no reason to  
>> disallow it.
>
> Section 11.6 gives an (informative) explanation why a full support  
> of SSRC multiplexing, which needs a mapping from SSRC values to  
> layers, is not provided in the memo. It does not really disallow  
> SSRC multiplexing, but the current draft as it is does not fully  
> support SSRC multiplexing either. We have two options. One is to  
> add back the mechanim we had once earlier for mapping of SSRC  
> values to layers. The other is to clarify better in section 11.6  
> that a full support of SSRC multiplexing needs a mapping from SSRC  
> values to layers, but is not specified in the document. Any  
> preference (or suggestion if you don't like either option)?

I don't think you need to add anything to this draft; rather just  
remove the prohibition in section 11.6.  There might be signalling  
issues to solve, but that's something for the MMUSIC draft, not here.

-- 
Colin Perkins
http://csperkins.org/