headers
Ye-Kui.Wang | 3 Sep 2007 14:53
Picon

RE: Comments on draft-ietf-avt-rtp-svc-02


Hi Magnus,

Thanks for your careful reading, thinking, and valuable comments. See replies inline. 

>1. Section 1, last sentence. I think you need to clarify the following.
> - That it uses its own identity rather then extending on the identity 
>of H.264.

Do you mean to clarify that it uses its own media subtype name "H264-SVC" other than "H264"?

> - That the deprecation only affects usage under SVC and not the normal
>H.264 payload format. I would change the word deprecates, removes to 
>indicate that it doesn't change any existing only removes a not needed 
>functionality.
>

Addressed already in the new version under working. See also in below (comment #7). 

>2. Section 3.2: I think this text is a bit unclear. It can to easily be 
>interpreted as that once an parameter set has been used it can't be 
>changed. But I assume that this hasn't been changed and that you can 
>change the active set and have the sets changed during the session by 
>overwriting them. I think you should tell when the sets can be changed, 
>rather also to make it clear. Because that do create some extra 
>complexity.
>

The content of an active sequence parameter set can only be changed at IDR access units (and each IDR access
unit starts a new "coded video sequence"), while the content of an active picture parameter set can be
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tom Taylor | 3 Sep 2007 15:45
Favicon

draft-xie-avt-forward-shifted-red-01.txt as WG item

Are there any objections to making draft-xie-avt-forward-shifted-red-01.txt an 
AVT Working Group item?  Please let us know within the next week.

Tom Taylor on behalf of the Chairs

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 3 Sep 2007 16:45
Picon
Favicon

Re: Comments on draft-ietf-avt-rtp-svc-02

Hi,

See comments inline. I removed all issues where I am satisfied with
resolution or answer.

Ye-Kui.Wang <at> nokia.com skrev:
> Hi Magnus,
> 
> Thanks for your careful reading, thinking, and valuable comments. See replies inline. 
> 
>> 1. Section 1, last sentence. I think you need to clarify the following.
>> - That it uses its own identity rather then extending on the identity 
>> of H.264.
> 
> Do you mean to clarify that it uses its own media subtype name "H264-SVC" other than "H264"?

Yes.

> 
>> 2. Section 3.2: I think this text is a bit unclear. It can to easily be 
>> interpreted as that once an parameter set has been used it can't be 
>> changed. But I assume that this hasn't been changed and that you can 
>> change the active set and have the sets changed during the session by 
>> overwriting them. I think you should tell when the sets can be changed, 
>> rather also to make it clear. Because that do create some extra 
>> complexity.
>>
> 
> The content of an active sequence parameter set can only be changed at IDR access units (and each IDR access
unit starts a new "coded video sequence"), while the content of an active picture parameter set can be
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ye-Kui.Wang | 3 Sep 2007 17:29
Picon

RE: Comments on draft-ietf-avt-rtp-svc-02


Thanks again! I further removed those items that are resolved or action
points agreed upon.

>>> 4. Section 5.1.2:
>>>
>>> "   RTP packet stream: A sequence of RTP packets with increasing
>>>   sequence numbers, identical PT and SSRC, carried in one 
>RTP session.
>>>   Within the scope of this memo, one RTP packet stream is 
>utilized to
>>>   transport an integer number of SVC Layers."
>>>
>>> I don't agree that the PT needs to be identical. However, for your 
>>> purposes I assume that it is great simpification not having 
>to think 
>>> about people using multiple PTs configured for carrying SVC 
>NAL units 
>>> for the same video sequence. I think you are introducing a 
>limitation 
>>> that doesn't need to exist, but has little practical value.
>>>
>> 
>> OK, will enable PT multiplexing in the new version. 
>
>I hope this only means that you will remove the restriction 
>you have entered, not recommending specific behaviors 
>regarding using multiple PTs.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Colin Perkins | 4 Sep 2007 11:47

Working group last call: draft-ietf-avt-rfc3119bis-05.txt

This is to announce a working group last call on the More Loss- 
Tolerant RTP Payload Format for MP3 Audio (draft-ietf-avt- 
rfc3119bis-05.txt). This draft corrects some minor mistakes in RFC  
3119 (see http://tinyurl.com/2c757d for details of the changes).

Please send any final comments on this draft to the list by 17  
September 2007. If no substantive issues are raised by that time, we  
will request the IESG consider this for publication as a Proposed  
Standard RFC, making RFC 3119 obsolete.

--

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

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Permalink | Reply | 1 comment |
headers
Colin Perkins | 4 Sep 2007 11:54

Re: Take draft-seokung-avt-seed-srtp-00.txt as a work item?

On 20 Aug 2007, at 19:56, Colin Perkins wrote:
> Begin forwarded message:
>> From: Internet-Drafts <at> ietf.org
>> Date: 6 August 2007 18:15:02 BDT
>> Subject: I-D ACTION:draft-seokung-avt-seed-srtp-00.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> 	Title		: The SEED Cipher Algorithm and Its Use with the Secure  
>> Real-time Transport Protocol (SRTP)
>> 	Author(s)	: S. Yoon, et al.
>> 	Filename	: draft-seokung-avt-seed-srtp-00.txt
>> 	Pages		: 6
>> 	Date		: 2007-8-6
>> 	
>>    This document describes the use of SEED block cipher algorithm  
>> in the
>>    Secure Real-time Transport Protocol [3] for confidentiality to the
>>    RTP traffic and to the control traffic for RTP, the Real-time
>>    Transport Control Protocol (RTCP).
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-seokung-avt-seed- 
>> srtp-00.txt
>
> This draft was briefly discussed at the recent AVT meeting in  
> Chicago. It appears to fit within our charter "to maintain and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Colin Perkins | 4 Sep 2007 16:55

Re: Working group last call: JPEG-2000 payload format

On 31 Aug 2007, at 15:56, Magnus Westerlund wrote:
> Colin Perkins skrev:
>> There was considerable discussion on the list in June about allowing
>> non-90kHz clock rates for the JPEG-2000 payload format. A new  
>> version of
>> the draft is now available, making the agreed change:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp- 
>> jpeg2000-16.txt
>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-jpeg2000- 
>> beam-07.txt
>>
>> If you commented previously, please review to confirm the changes  
>> made
>> reflect the consensus. If there are no additional comments by 20th
>> August, we will request the IESG consider these drafts for  
>> publication.
>>
>
> Even if late, I think it looks okay. I am missing some recommendations
> on not using timestamp rate below 1000.

That's a good point, and something we discussed previously. Can you  
suggest text?

--

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

_______________________________________________
(Continue reading)

Permalink | Reply | 2 comments |
headers
Regis Crinon | 4 Sep 2007 06:54
Picon

Inquiry about RFC 4629 (optional parameters in SDP)

Hello everyone,

 

I have the following question regarding RFC 4629. I would really appreciate your feedback.

Thank you in advance,

 

Regis J. Crinon

 

 

Fact 1:

 

H.263+ includes a set of new Annexes: Annex I through T.

 

Fact 2:

 

RFC 4629 account for ONLY a subset of these annexes. See excerpts from the RFC below:

 

A list of optional annexes specifies which annexes of H.263 are

      supported.  The optional annexes are defined as part of H263-1998,

      H263-2000.  H.263 annex X [H263] defines profiles that group

      annexes for specific applications.  A system that supports a

      specific annex SHALL specify its support using the optional

      parameters.  If no annex is specified, then the stream is Baseline

      H.263.

 

      The allowed optional parameters for the annexes are "F", "I", "J",

      "T", "K", "N", and "P".

 

Question

 

How are the other annexes signaled? Example: How can I signal that an H.263+ bistream uses Annex L or Annex M or Annex O or Annex Q or Annex R or Annex S? It seems that I cannot use SDP to tell a video bitstream that uses one or more of these annexes from one that does not. Hence the question.

 

 

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Permalink | Reply | 502 comments |
headers
Even, Roni | 4 Sep 2007 19:18
Picon

RE: Inquiry about RFC 4629 (optional parameters in SDP)

Hi,

The reason for this selection of annexes was based on the ones being used by products in the markets.  There is no need to specify parameters that are not used.

You can also use annex X based profiles for specifying other application based profile.

Roni Even

 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
A consensus means that everyone agrees to say collectively what no one believes individually
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

From: Regis Crinon [mailto:regisc <at> exchange.microsoft.com]
Sent: Tuesday, September 04, 2007 7:54 AM
To: avt <at> ietf.org
Subject: [AVT] Inquiry about RFC 4629 (optional parameters in SDP)

 

Hello everyone,

 

I have the following question regarding RFC 4629. I would really appreciate your feedback.

Thank you in advance,

 

Regis J. Crinon

 

 

Fact 1:

 

H.263+ includes a set of new Annexes: Annex I through T.

 

Fact 2:

 

RFC 4629 account for ONLY a subset of these annexes. See excerpts from the RFC below:

 

A list of optional annexes specifies which annexes of H.263 are

      supported.  The optional annexes are defined as part of H263-1998,

      H263-2000.  H.263 annex X [H263] defines profiles that group

      annexes for specific applications.  A system that supports a

      specific annex SHALL specify its support using the optional

      parameters.  If no annex is specified, then the stream is Baseline

      H.263.

 

      The allowed optional parameters for the annexes are "F", "I", "J",

      "T", "K", "N", and "P".

 

Question

 

How are the other annexes signaled? Example: How can I signal that an H.263+ bistream uses Annex L or Annex M or Annex O or Annex Q or Annex R or Annex S? It seems that I cannot use SDP to tell a video bitstream that uses one or more of these annexes from one that does not. Hence the question.

 

 

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Permalink | Reply | 502 comments |
headers
Randell Jesup | 4 Sep 2007 19:36

Re: Inquiry about RFC 4629 (optional parameters in SDP)

"Even, Roni" <roni.even <at> polycom.co.il> writes:
>The reason for this selection of annexes was based on the ones being
>used by products in the markets.  There is no need to specify parameters
>that are not used.

Ummm... that just seems totally confused to me.  We won't provide a way
to negotiate feature X because no one currently uses feature X - but if you
can't negotiate it, what use is it to implement it?  (Other than in a 
private, non-RFC-based, non-interoperable setup.)

It just asks people to either ignore the standard and go totally
proprietary, extend it ad-hoc and quite possibly incompatibly, or
cut off any work on using those annexes ever.

>You can also use annex X based profiles for specifying other application
>based profile.

Which is basically a private, incompatible negotiation.

I realize this is the way the RFC is; I'm just wondering as to why.  Maybe
the point was no one had implemented them and the WG believed no would
would implement them for good reason, and they were effectively deprecated.

--

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup <at> wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Permalink | Reply | 3 comments |

Gmane