Internet-Drafts | 2 Apr 2010 14:00
Picon
Favicon

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 2010 15:19
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 2010 20:47
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 2010 20:51
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 2010 22:21
Favicon

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
> To: info <at> spiritdsp.com
> Cc: iesg <at> ietf.org, secdir <at> ietf.org
> 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
(Continue reading)

Ali C. Begen (abegen | 4 Apr 2010 03:19
Picon
Favicon

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
(Continue reading)

Internet-Drafts | 5 Apr 2010 01:15
Picon
Favicon

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

(Continue reading)

Roni Even | 5 Apr 2010 10:05
Favicon

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
(Continue reading)

Ye-Kui Wang | 5 Apr 2010 15:50
Favicon

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
(Continue reading)

RFC Errata System | 5 Apr 2010 12:43
Favicon

[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'.
(Continue reading)


Gmane