Internet-Drafts | 2 Apr 14:00 2010
Picon

I-D Action:draft-ietf-avt-rfc3016bis-00.txt

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 MPEG-4 Audio/Visual Streams
	Author(s)       : M. Schmidt, et al.
	Filename        : draft-ietf-avt-rfc3016bis-00.txt
	Pages           : 32
	Date            : 2010-04-02

This document describes Real-Time Transport Protocol (RTP) payload
formats for carrying each of MPEG-4 Audio and MPEG-4 Visual
bitstreams without using MPEG-4 Systems.  For the purpose of directly
mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides
specifications for the use of RTP header fields and also specifies
fragmentation rules.  It also provides specifications for Media Type
registration and the use of Session Description Protocol (SDP).

Comments are solicited and should be addressed to the working group's
mailing list at avt <at> ietf.org and/or the author(s).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3016bis-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.
(Continue reading)

Bont, Frans de | 2 Apr 15:19 2010
Picon

Re: I-D Action:draft-ietf-avt-rfc3016bis-00.txt

Hi all,

We have submitted a slightly updated version of draft-schmidt-avt-rfc3016bis-03
as a WG document, accordingly the request of the AVT chairs dated March 16th.
A link to this Internet-Draft can be found in the announcement.

Changes with respect to the -03 version are:
- In section 5.4.8, the value of the config parameter has been corrected
- In section 5.4.10 an additional audio signaling example has been added
- The reference to MPEG-4 Video has been updated
- The nits have been addressed.

Your comments are welcome!

Best regards,
Frans

> -----Original Message-----
> From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org] On Behalf Of
> Internet-Drafts <at> ietf.org
> Sent: 2010 Apr 02 2:00 PM
> To: i-d-announce <at> ietf.org
> Cc: avt <at> ietf.org
> Subject: [AVT] I-D Action:draft-ietf-avt-rfc3016bis-00.txt
>
> 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.
>
(Continue reading)

Miguel Garcia | 2 Apr 20:47 2010
Picon

3rd CfP: ICCGI 2010 || September 20-25, 2010 - Valencia, Spain


3rd CfP: ICCGI 2010 || September 20-25, 2010 - Valencia, Spain

INVITATION:

=================
Please consider to contribute to and/or forward to the appropriate 
groups the following opportunity to submit and publish original 
scientific results.
=================

============== ICCGI 2010 | Call for Papers ===============

CALL FOR PAPERS, TUTORIALS, PANELS

ICCGI 2010: The Fifth International Multi-Conference on Computing in the 
Global Information Technology
September 20-25, 2010 - Valencia, Spain

General page: http://www.iaria.org/conferences2010/ICCGI10.html
Call for Papers: http://www.iaria.org/conferences2010/CfPICCGI10.html

Submission deadline: April 20, 2010

Sponsored by IARIA, www.iaria.org
Co-sponsored by IEEE Spain, Illinois State University, University 
Politehnica Bucharest, Universidad Politecnica de Valencia, La 
Machinista Valenciana, IGIC, Hydro-Quebec, Ruder Boskovic Institute,
Orange, Universidad Complutense Madrid

(Continue reading)

Miguel Garcia | 2 Apr 20:51 2010
Picon

3rd CfP: ACCESS 2010 || September 20-25, 2010 - Valencia, Spain


3rd CfP: ACCESS 2010 || September 20-25, 2010 - Valencia, Spain

INVITATION:

=================
Please consider to contribute to and/or forward to the appropriate groups the following opportunity to
submit and publish original scientific results.
=================

============== ACCESS 2010 | Call for Papers ===============

CALL FOR PAPERS, TUTORIALS, PANELS

ACCESS 2010: The First International Conferences on Access Networks, Services and Technologies
September 20-25, 2010 - Valencia, Spain

General page: http://www.iaria.org/conferences2010/ACCESS10.html
Call for Papers: http://www.iaria.org/conferences2010/CfPACCESS10.html

Submission deadline: April 20, 2010

Sponsored by IARIA, www.iaria.org
Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org
Publisher: CPS ( see: http://www2.computer.org/portal/web/cscps )
Archived: IEEE CSDL (Computer Science Digital Library) and IEEE Xplore
Submitted for indexing: Elsevier's EI Compendex Database, EI's Engineering Information Index
Other indexes are being considered: INSPEC, DBLP, Thomson Reuters Conference Proceedings Citation Index

Please note the Poster Forum and Work in Progress options.
(Continue reading)

Robert Sparks | 2 Apr 22:21 2010

Fwd: secdir review of draft-ietf-avt-rtp-ipmr-12.txt

fyi

Begin forwarded message:

From: Juergen Schoenwaelder <j.schoenwaelder <at> jacobs-university.de>
Date: March 5, 2010 7:55:54 AM CST
Subject: secdir review of draft-ietf-avt-rtp-ipmr-12.txt
Reply-To: Juergen Schoenwaelder <j.schoenwaelder <at> jacobs-university.de>

Hi.

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document defines how SPIRIT IP-MR encoded speech signals can be
transported over RTP. The security considerations seem to be adequate.
However, I am concerned about the C code in the appendix extracting
frame information. The code does not seem to do proper bound checking,
which I think is a problem that needs to be fixed. I understand that
the frame size is an out parameter - still the size of the buffer
passed via pCoded should be available so that proper bound checking
can be performed.

Other than that, I noticed a number of editorial issues, mostly due to
missing articles etc. I am attaching a unified context diff correcting
some of the issues (but note that I stopped making changes at the end
of section 3 - so there is likely more to fix).

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
--- draft-ietf-avt-rtp-ipmr-12.txt	2010-03-05 14:34:16.000000000 +0100
+++ draft-ietf-avt-rtp-ipmr-12-js.txt	2010-03-05 14:51:08.000000000 +0100
 <at>  <at>  -124,7 +124,7  <at>  <at> 

 2. IP-MR Codec Description 

-The IP-MR codec is scalable adaptive multi-rate wideband speech codec 
+The IP-MR codec is a scalable adaptive multi-rate wideband speech codec 
 designed by SPIRIT for use in IP based networks. These codec is suitable
 for real time communications such as telephony and videoconferencing. 

 <at>  <at>  -141,12 +141,12  <at>  <at> 
 layer and several enhancement layers which are coded independently. 
 Only the core layer is mandatory to decode understandable speech and
 upper layers provide quality enhancement. These enhancement layers 
-may be omitted and remaining base layer can be meaningfully decoded
+may be omitted and the remaining base layer can be meaningfully decoded
 without artifacts. This makes the bit stream scalable and allows 
 to reduce bit rate during transmission without re-encoding. 

 This memo specifies an optional form of redundancy coding within RTP 
-for protection against packet loss. It is based on commonly known 
+for protection against packet loss. It is based on a commonly known 
 scheme when previously transmitted frames are aggregated together 
 with new ones. Each frame is retransmitted once in the following 
 RTP payload packet. f(n-2)...f(n+4) denotes a sequence of speech 
 <at>  <at>  -242,7 +242,7  <at>  <at> 
 3.2. Payload Format Structure 

 The IP-MR payload format consists of a payload header with general 
-information about packet, a speech table of contents (TOC), and speech
+information about a packet, a speech table of contents (TOC), and speech
 data. An optional redundancy section follows after speech data. The 
 redundancy section consists of redundancy header, redundancy TOC and 
 redundancy data payload. 
 <at>  <at>  -307,7 +307,7  <at>  <at> 

     o D (1 bit): reserved. Must be always set to 1. 
       Previously, this bit indicated DTX mode availability, but in fact
-      payload dublicates this information.
+      payload duplicates this information.

     o A (1 bit): reserved. Must be always set to 1. 
       Previously, this bit indicated aligned mode, but this mode has 
 <at>  <at>  -322,7 +322,7  <at>  <at> 

 3.4. Speech Table of Contents 

-The speech TOC contains entries for each frame in packet (grouping size
+The speech TOC contains entries for each frame in a packet (grouping size
 in total). Each entry contains a single field: 

                                    0
 <at>  <at>  -341,7 +341,7  <at>  <at> 
       lost frame itself or by empty frames generated by the encoder 
       during silence intervals in DTX mode. 

-Note that if CR flag from payload header is 7 (NO_DATA) then speech TOC 
+Note that if the CR flag from the payload header is 7 (NO_DATA) then the speech TOC 
 is empty. 

 3.5. Speech Data 
 <at>  <at>  -350,30 +350,30  <at>  <at> 
 noise frames, as specified in the speech TOC of the payload. 

 Each speech frame represents 20 ms of speech encoded with the rate 
-indicated in the CR and base rate indicated in BR field of the payload 
+indicated in the CR field and the base rate indicated in the BR field of the payload 
 header. 

-The size of coded speech frame is variable due to the nature of codec. 
-The Encoder's algorithm decides what size of each frame is and returns 
+The size of the coded speech frame is variable due to the nature of codec. 
+The Encoder's algorithm decides the size of each frame and returns 
 it after encoding. In order to save bandwidth the size is not placed 
-into payload obviously. The frame size can be determined by frame's 
+into the payload. The frame size can be determined by frame's 
 content using a special service function specified in Appendix A. 
-This function provides complete information about coded frame including
-size, number of layers, size of each layer and size of perceptual 
+This function provides complete information about the coded frame including
+its size, the number of layers, the size of each layer and the size of perceptual 
 sensitive classes.

 3.6. Redundancy Header 

 If a packet contains redundancy (R field of payload header is 1) the 
-speech data is followed by redundancy header: 
+speech data is followed by the redundancy header: 

                              0 1 2 3 4 5
                             +-+-+-+-+-+-+
                             | CL1 | CL2 |
                             +-+-+-+-+-+-+

-Redundancy header consists of two fields. Each field contains class 
-specifier for amount of redundancy partly taken from the preceding 
+The redundancy header consists of two fields. Each field contains class 
+specifier for the amount of redundancy partly taken from the preceding 
 packet (CL1) and pre-preceding packet (CL2), e.g. distant from the 
 current packet by 1 and 2 packets accordingly. The values are listed 
 in the table below: 
 <at>  <at>  -409,20 +409,20  <at>  <at> 
 Each specifier takes 3 bits, thus the total redundancy header size is 6 
 bits. 

-These classes indicate subjective importance of bits from core layer. 
-Class A contains the bits most sensitive to errors and lost of these 
+These classes indicate the subjective importance of bits from the core layer. 
+Class A contains the bits most sensitive to errors and loss of these 
 bits results in a corrupted speech frame which should not be decoded 
-without applying packet loss concealment (PLC) procedure. Class B is 
+without applying a packet loss concealment (PLC) procedure. Class B is 
 less sensitive than class A and so on to F. Sum of all bit classes 
 from A to F composes core layer.

-Putting some part (classes of bits) from previous frame into current 
-packet makes possible to partially decode previous frame in case of 
-it's lost. Than more information is delivered than less speech quality 
-degradation will be. Flags CL1 and CL2 specify how many classes from 
-previous frames current packet contain. E.g. CL1=3 (class C), it means 
-that packet contains bits from classes A, B and C of previous frame. 
-If CL1=6 (class F) then whole core layer is included.
+Putting some part (classes of bits) from a previous frame into the current 
+packet makes it possible to partially decode a previous frame in case it
+got lost. Since more information is delivered, less speech quality 
+degradation will be observed. The flags CL1 and CL2 specify how many classes from 
+previous frames the current packet contain. For example, CL1=3 (class C) means 
+that the packet contains bits from classes A, B and C of the previous frame. 
+If CL1=6 (class F) then the whole core layer is included.

 3.7. Redundancy Table of Contents 

 <at>  <at>  -432,7 +432,7  <at>  <at> 
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The redundancy TOC contains entries for redundancy frames from preceding 
-and pre-preceding packets. Each entry takes 1 bit like speech TOC entry 
+and pre-preceding packets. Each entry takes 1 bit like the speech TOC entry 
 (3.3):

                                    0
 <at>  <at>  -453,21 +453,21  <at>  <at> 
       is equal to the grouping size of the current packet. E.g. maximum 
       number of entries is 4*2 = 8. 

-    o If class specifier in the redundancy header is CL=0 (NO_DATA) 
-      then there is no entries for corresponding packet redundancy. 
+    o If the class specifier in the redundancy header is CL=0 (NO_DATA) 
+      then there are no entries for corresponding packet redundancy. 

 
 3.8. Redundancy Data 

-Redundancy data of a payload contains redundancy information for one or 
+The redundancy data of the payload contains redundancy information for one or 
 more speech frames or comfort noise frames that may be lost during 
 transition, as specified in the redundancy TOC of the payload. Actually 
 redundancy is the most important part of preceding frames representing 
 20 ms of speech. This data MAY be used for partial reconstruction of 
-lost frames. The amount of available redundancy is specified by CL flag 
-in redundancy header section (3.5). This flag SHOULD be passed to 
+lost frames. The amount of available redundancy is specified by the CL flag 
+in the redundancy header section (3.5). This flag SHOULD be passed to the
 decoder. The size of redundancy frame is variable and can be obtained 
-using service function specified in Appendix A.
+using the service function specified in Appendix A.

 
 4. Payload Examples 


_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Ali C. Begen (abegen | 4 Apr 03:19 2010
Picon

FW: New Version Notification for draft-begen-avt-rtcp-port-for-ssm-01

Based on the feedback given in Anaheim, I revised the 'multicast-rtcp' attribute draft. 
http://www.ietf.org/id/draft-begen-avt-rtcp-port-for-ssm-01.txt 

It is a short read. Let me know if I missed any comments. The next revision of RAMS will be using this new
attribute. So, I would like to request a WG adoption.

Thanks,
-acbegen

-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org] 
Sent: Saturday, April 03, 2010 9:16 PM
To: Ali C. Begen (abegen)
Subject: New Version Notification for draft-begen-avt-rtcp-port-for-ssm-01 

A new version of I-D, draft-begen-avt-rtcp-port-for-ssm-01.txt has been successfully submitted by Ali
Begen and posted to the IETF repository.

Filename:	 draft-begen-avt-rtcp-port-for-ssm
Revision:	 01
Title:		 RTP Control Protocol (RTCP) Port for Multicast Sessions
Creation_date:	 2010-04-03
WG ID:		 Independent Submission
Number_of_pages: 7

Abstract:
The Session Description Protocol (SDP) has an attribute that allows
RTP applications to specify an address and a port associated with the
RTP Control Protocol (RTCP) traffic.  In RTP-based source-specific
multicast (SSM) sessions, the same attribute is used to designate the
address and the RTCP port of the Feedback Target in the SDP
description.  However, the RTCP port associated with the SSM session
itself cannot be specified by the same attribute to avoid ambiguity,
and thus, is required to be derived from the "m=" line of the media
description.  Similarly, in any-source multicast (ASM) sessions,
there is no explicit way to specify the destination RTCP port.
Deriving the RTCP port from the "m=" line imposes an unnecessary
restriction.  This document removes this restriction by introducing a
new SDP attribute.

The IETF Secretariat.

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt

Internet-Drafts | 5 Apr 01:15 2010
Picon

I-D Action:draft-ietf-avt-rtp-rfc3984bis-10.txt

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-10.txt
	Pages           : 104
	Date            : 2010-04-04

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, excluding the
Scalable Video Coding (SVC) extension and the Multivew Video Coding
extension, for which the RTP payload formats are defined elsewhere.
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 obsoletes RFC 3984.  Changes from RFC 3984 are summarized
in section 15.  Issues on backward compatibility to RFC 3984 are
discussed in section 14.

Table of Contents

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-rfc3984bis-10.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.
Attachment (draft-ietf-avt-rtp-rfc3984bis-10.txt): message/external-body, 70 bytes
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Roni Even | 5 Apr 10:05 2010

Re: Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt

Stuart,
Looking again at your question I think that I gave the wrong answer before.
H.264 says that if you support a level you also support the lower ones, it
does not discuss any specific resolution and you cannot assume a resolution.
For example if the signaled level is 2.1 the encoder can send also QCIF with
compliance with level 1.0. The level signaled is not a request for a
specific resolution.
If the receiver wants to receive a picture with a specific resolution it
should use signaling like the image attribute draft in MMUSIC or H.241 for
H.323 systems. Note that in these two drafts it discusses that the encoder
may not be able to provide the requested resolution and can provide one
closer to it in order to reduce bw on the wire and processing for scaling
and cropping

Roni

> -----Original Message-----
> From: Stuart Taylor (sttaylor) [mailto:sttaylor <at> cisco.com]
> Sent: Thursday, February 18, 2010 5:06 PM
> To: Roni Even
> Cc: Ye-Kui Wang; avt <at> ietf.org
> Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt
> 
> Roni,
> 
> I guess I'm having trouble with the semantics.  Consider the statement:
> "For either receiving or sending, all levels that are lower than the
> highest level supported MUST also be supported."  For the sender, is
> this only saying that the encoder must not violate the negotiated
> constraints by, for instance, sending 720p to a level 2.0 receiver?  If
> so, that seems like a convoluted way to express the requirement.
> 
> Put another way, does this mean that an encoder that only produces
> 720p,
> CIF or QCIF, with the QCIF compliant with level 1.0, is fully compliant
> provided it doesn't violate the receiver's advertised level?
> 
> Stuart
> 
> 
> 
>  -----Original Message-----
> From: Roni Even [mailto:Even.roni <at> huawei.com]
> Sent: Thursday, February 18, 2010 4:05 AM
> To: Stuart Taylor (sttaylor)
> Cc: 'Ye-Kui Wang'; avt <at> ietf.org
> Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt
> 
> Hi Stuart,
> 
> About
> "First, it's common for an endpoint to have a lower
> resolution camera than display.  In that case it may negotiate for the
> display and then send at a lower level.  This works even if level
> asymmetry is not supported by the other endpoint"
> 
> this is allowed since the negotiated level define a maximum and not
> precise
> values. The decoder should be able to scale (up or down) to the display
> it
> is using.
> Yet the encoder does not send at lower level, it still supports the
> negotiated  level but is sending at lower operation point. Sending at
> lower
> level can be achieved by defining a sendonly and recvonly m lines.
> Roni
> 
> 
> > -----Original Message-----
> > From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org] On Behalf Of
> > Stuart Taylor (sttaylor)
> > Sent: Wednesday, February 17, 2010 4:50 PM
> > To: Ye-Kui Wang; avt <at> ietf.org
> > Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt
> >
> > YK & BR,
> >
> > Thank you for your consideration.  Some responses in line.
> >
> > Stuart
> >
> >
> > -----Original Message-----
> > From: Ye-Kui Wang [mailto:yekuiwang <at> huawei.com]
> > Sent: Tuesday, February 16, 2010 6:28 PM
> > To: Stuart Taylor (sttaylor); avt <at> ietf.org
> > Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-rfc3984bis-09.txt
> >
> >
> >
> > Hi Stuart,
> >
> > Thanks for your new comments. Please see my replies below.
> >
> > > ---
> > >
> > > Page 41, 2nd paragraph, says:
> > >          "If the profile-level-id parameter is used to indicate
> > >           properties of a NAL unit stream, it indicates that,
> > > to decode
> > >           the stream, the minimum subset of coding tools a decoder
> > has
> > >           to support is the default sub-profile, and the lowest
> level
> > >           the decoder has to support is the default level."
> > >
> > > I think that should say "[...], and the *highest* level the
> > > decoder has to support [...]"
> > >
> >
> > No, the original text is correct. Decoders that are more powerful can
> > decode
> > bitstreams that require less powerful decoders. For example, a
> > bitstream
> > marked as level 1 requires that the lowest level a decoder has to
> > support is
> > level 1. A decoder supporting level 2 also satisfies the requirement.
> >
> > [ST] I still find this text to be confusing: "and the lowest level
> the
> > decoder has to support is the default level" implies the decoder
> > doesn't
> > have to support any level below the default level and might need to
> > support a level higher than the default level.
> >
> > > ---
> > >
> > > In the next paragraph:
> > >          "[...] For either
> > >           receiving or sending, all levels that are lower than the
> > >           highest level supported MUST also be supported."
> > >
> > > I think that should say "[...] For receiving, all levels
> > > [...]".  As currently worded this indicates the encoder must
> > > support all levels below the negotiated one.  However, since
> > > the level is always downgradeable, it should be sufficient to
> > > encode any one level that is equal to or less than the
> > > negotiated level.  In contrast, it is important for a decoder
> > > to handle all levels below the maximum.
> > >
> >
> > So you think there are good encoders that can encode level 2
> bitstreams
> > but
> > cannot encode level 1 bitstreams?
> >
> > In any case, if we make the change here by removing "or sending",
> then
> > the
> > level downgrading feature would be problematic. For example, when the
> > offerer offers level 2, while the answerer answers level 1, without
> the
> > presence of the parameters newly defined in the bis draft in either
> the
> > offer or the answer, then level 1 is used in both directions. This
> can
> > only
> > work based on that the offerer can encode the offered level (2) and
> any
> > lower level.
> >
> > [ST] Actually, a lot of encoders support a subset of levels, for at
> > least two reasons.  First, it's common for an endpoint to have a
> lower
> > resolution camera than display.  In that case it may negotiate for
> the
> > display and then send at a lower level.  This works even if level
> > asymmetry is not supported by the other endpoint. Second, it's
> > expensive
> > to test the full set of levels, particularly if there is no perceived
> > market need for all of them.  As long as the encoder can support
> level
> > 1.0, it should be compliant with the requirement.  Support of
> anything
> > higher should be based on perceived market need rather than forced by
> > standards.
> >
> > > ---
> > >
> > > Page 42, bottom paragraph says:
> > >           "If a receiver can support all the properties of
> > > level A, the
> > >           highest level specified in the value of the profile-
> level-
> > id
> > >           parameter or the max-recv-level parameter MUST be level A
> > >           (i.e. MUST NOT be lower than level A).  In other words, a
> > >           receiver MUST NOT signal values of max-mbps,
> > > max-fs, max-cpb,
> > >           max-dpb, and max-br that taken together meet the
> > > requirements
> > >           of a higher level compared to the highest level specified
> > in
> > >           the value of the profile-level-id parameter or the max-
> > recv-
> > >           level parameter."
> > >
> > > The first sentence goes beyond a prohibition against using
> > > the optional parameters inappropriately: it further requires
> > > a level advertisement to always indicate the maximum level
> > > that can be decoded.  I don't think that further requirement
> > > is necessary, and is certainly not enforceable.
> > >
> > > I suggest the following alternative:
> > >
> > >           These optional parameters MUST NOT be used to advertise
> the
> > >           capability to receive at a level higher than indicated by
> > >           the max-recv-level or profile-level-id parameters.
> > > In other words,
> > >           if a receiver advertises level A with max-recv-level or
> > >           profile-level-id, and the receiver is fully capable
> > > of decoding
> > >           a higher level B, the receiver MUST NOT signal
> > > values of max-mbps,
> > >           max-fs, max-cpb, max-dpb, and max-br that taken
> > > together meet all
> > >           the requirements of level B.
> >
> > This was originated from RFC 3984. To me this restriction is
> reasonable
> > - it
> > forces the profile-level-id to tell the truth. It does not make sense
> > to
> > me
> > to label a decoder capable of decoding level 2 bitstreams with level
> 1.
> > BTW,
> > why this restriction is not enforceable?
> >
> > [ST] I agree it is in RFC 3984.  It's not enforceable (or detectable)
> > because the maximum capabilities are not exposed unless the endpoint
> > chooses to do so.  There is no interoperability benefit to this
> > prescription beyond what market forces are likely to require, so I
> > would
> > choose to leave this up to endpoint vendors to decide.
> >
> > Note that advertising a lower level can be a useful tool for adapting
> > to
> > a variety of conditions.  It may be, for example, that a receiver
> would
> > want to force the level down to 2.0 (CIF) in favor of having to
> support
> > streams coming in at an intermediate level if conditions don't allow
> > level 3.1 (720p).
> >
> > > ---
> > >
> > > Page 67, top paragraph, says:
> > >    "Parameters declaring a configuration point are not
> > > changeable, with
> > >    the exception of the level part of the "profile-level-id"
> > parameter
> > >    for unicast usage.  This expresses values a receiver expects to
> be
> > >    used and must be used verbatim on the sender side."
> > >
> > > I suggest changing "This expresses" to "These express".  That
> > > should make it clearer that the second sentence refers to the
> > > configuration point parameters (plural) rather than the level
> > > (singular).
> > >
> >
> > Agreed.
> >
> > > ---
> > >
> > > When there are multiple offers in an m-line, is it required
> > > that all formats are distinguishable by a difference in a
> > > configuration point parameter (again, excluding the level)?
> > > I think it should be required, but I don't see where it is
> > > stated.  I suggest:
> > >
> > >         When multiple configuration offers are made, they
> > > MUST be distinguishable
> > >         by differences in the packetization mode and/or
> > > profile-level-id, excluding the
> > >         level part of the profile-level-id.
> > >
> >
> > I think it is good not to have this restriction, as different offers
> > may
> > differ by other parameters as well, e.g. those buffering parameters
> for
> > the
> > interleaved packetization mode.
> >
> > [ST] In that case the position should be stated and we should have
> > clear
> > rules for how to match answers to offers that take this into account.
> > Note that this creates a potential ambiguity if the same PT is not
> > usable in an answer.  Currently it is permissible to answer with a
> > different PT and then the configuration point parameters are used to
> > create the match.  An example of a troublesome case is where a B2BUA
> > (such as Cisco Unified Communications Manager) is trying to match
> > capabilities between two offers with conflicting PT numbers.
> >
> > BR, YK
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt

Ye-Kui Wang | 5 Apr 15:50 2010

Re: I-D Action:draft-ietf-avt-rtp-rfc3984bis-10.txt


The only change compared to -09 is as follows (thanks to Stuart Taylor for
pointing out the bug): 

- Page 67, top paragraph, change "This expresses" to "These express" in the
following sentence: 
>    "Parameters declaring a configuration point are not changeable, with
>    the exception of the level part of the "profile-level-id" parameter
>    for unicast usage.  This expresses values a receiver expects to be
>    used and must be used verbatim on the sender side."

BR, YK

> -----Original Message-----
> From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org] On 
> Behalf Of Internet-Drafts <at> ietf.org
> Sent: Sunday, April 04, 2010 7:15 PM
> To: i-d-announce <at> ietf.org
> Cc: avt <at> ietf.org
> Subject: [AVT] I-D Action:draft-ietf-avt-rtp-rfc3984bis-10.txt
> 
> 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-10.txt
> 	Pages           : 104
> 	Date            : 2010-04-04
> 
> 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, excluding the Scalable Video Coding (SVC) extension 
> and the Multivew Video Coding extension, for which the RTP 
> payload formats are defined elsewhere.
> 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 obsoletes RFC 3984.  Changes from RFC 3984 are 
> summarized in section 15.  Issues on backward compatibility 
> to RFC 3984 are discussed in section 14.
> 
> 
> 
> Table of Contents
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-rfc3984
> bis-10.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
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt

RFC Errata System | 5 Apr 12:43 2010

[Technical Errata Reported] RFC5760 (2111)


The following errata report has been submitted for RFC5760,
"RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5760&eid=2111

--------------------------------------
Type: Technical
Reported by: ALfred Hoenes <ah <at> TR-Sys.de>

Section: 7.4, pg.34

Original Text
-------------
[[  first paragraph on page 34: ]]

|  The RTP receiver MUST process the report blocks contained in any RTP
   SR and RR packets to complete its view of the RTP session.

Corrected Text
--------------
|  The RTP receiver MUST process the report blocks contained in any RTCP
   SR and RR packets to complete its view of the RTP session.

Notes
-----
Rationale; distinction between RTP and RTCP is significant;
  therefore classified as 'Technical'.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5760 (draft-ietf-avt-rtcpssm-19)
--------------------------------------
Title               : RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback
Publication Date    : February 2010
Author(s)           : J. Ott, J. Chesterfield, E. Schooler
Category            : PROPOSED STANDARD
Source              : Audio/Video Transport
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt


Gmane