Audio/Video Transport (avt)

Internet-Drafts | 1 Dec 2008 21:00

I-D ACTION:draft-ietf-avt-rtp-atrac-family-20.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 Adaptive TRansform Acoustic Coding (ATRAC) Family
	Author(s)	: J. Matsumoto, M. Hatanaka
	Filename	: draft-ietf-avt-rtp-atrac-family-20.txt
	Pages		: 35
	Date		: 2008-12-1
	
This document describes an RTP payload format for efficient and
   flexible transporting of audio data encoded with the Adaptive
   TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements
   to the ATRAC family of codecs support high quality audio coding with
   multiple channels.  The RTP payload format as presented in this
   document also includes support for data fragmentation, elementary
   redundancy measures, and a variation on scalable streaming.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-20.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-atrac-family-20.txt): message/external-body, 69 bytes

(Continue reading)

headers

Tom Taylor | 2 Dec 2008 04:27

Editorial comments on draft-ietf-avt-rtp-mps-01.txt

Here are my promised comments, a bit later than I intended.

1. Idnits results
    ==============
Idnits has a couple of complaints. If it's convenient, you should use the latest 
version of the boilerplate text. idnits also flags a line that is too long by 
one character. It is the second line of the first paragraph of section 3.1. This 
obviously happened because the tool you were using didn't count characters after 
it expanded your references. If necessary, I suggest changing the wording (e.g., 
use "given here" instead of "summed up"). Or you could simply manually correct 
the compiled text by moving "summed" to the start of the next line.

Idnits also complains that your text has no formfeed characters. XML2RFC puts 
them in for me, though I have to use a hex editor afterwards to convert 
end-of-line x'0a' into x'0d0a'.

2. Comments on your IANA section
    ===============================
There has been no comment back from the media types list. However, I have a 
couple of comments of my own.

a) Opening paragraph of section 5: are you talking about mpeg-generic as a 
general subtype, or should you specify audio/mpeg-generic.

b) In section 5.2, I'm afraid you have a little more to do. You have to create a 
new registry for sub-parameters when mode=AAC-lbr and AAC-hbr respectively. See 
  http://www.iana.org/assignments/media-type-sub-parameters for an example with 
mode=RTP-midi.

3. Small stuff

(Continue reading)

headers

Internet-Drafts | 2 Dec 2008 20:15

I-D ACTION:draft-ietf-avt-rtp-atrac-family-21.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 Adaptive TRansform Acoustic Coding (ATRAC) Family
	Author(s)	: J. Matsumoto, M. Hatanaka
	Filename	: draft-ietf-avt-rtp-atrac-family-21.txt
	Pages		: 35
	Date		: 2008-12-2
	
This document describes an RTP payload format for efficient and
   flexible transporting of audio data encoded with the Adaptive
   TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements
   to the ATRAC family of codecs support high quality audio coding with
   multiple channels.  The RTP payload format as presented in this
   document also includes support for data fragmentation, elementary
   redundancy measures, and a variation on scalable streaming.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-21.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-atrac-family-21.txt): message/external-body, 69 bytes

(Continue reading)

headers

Magnus Westerlund | 3 Dec 2008 19:19

Clock Skew update issue for layered codecs

Hi,

I wanted to start a separate thread on this particular issue with
multi-layered codecs.

Lets assume that we have 3 layers produced by the media codec from a
single media source (microphone). We have some clock skew on the audio
card sampling clock that will need to be communicated at least now and
then to keep this under control.

The transmission of RTCP SR will happen at regular intervals in each
layer but the jittering will make this transmission into a random
process on the short time scale.

In the below figure each x is an RTCP packet, the y is when the RTCP SR
information has been updated for the clock skew.

          123456789ABCDE
A ---x----x----y--y----y

B -x----x--x----y---y---

C --x--x---x--x---y----y

So the big question here is when a receiver can take the clock skew
compensation into consideration and apply it to the actual playout?

A time 1 all layers have the same synch information. At time 6 layer A
receives the clock skew update in the RTCP SR. At this point it could
apply it to this layer. However, to avoid misaligning the audio frames

(Continue reading)

headers

Magnus Westerlund | 3 Dec 2008 19:29

How to correctly group multiple source of the same media type when using layered codecs

Hi,

Another issue with layered codecs is how to determine which SSRC's in
the different layers actually are part of the same source. The immediate
reaction is of course to use SDES cname mechanism and group the SSRC
with the matching cname in each layer. That works as long as one doesn't
have more than one source (microphone, video camera, etc) in the same
RTP session that needs to be synchronized.

In the non-multilayered case this is not an issue, as each SSRC is
providing a completely contained stream and encoding. But in the
multilayered case you can get this:

Layer a:

SSRC X: CNAME=Charlie
SSRC Y: CNAME=Charlie

Layer b:

SSRC Z: CNAME=Charlie
SSRC Q: CNAME=Charlie

So how do you determine that X and Q are one source and Y and Z are the
other?

The immediate solution is of course align the SSRC values between the
layers. An alternative is to define additional SDES items that provides
a second layer of information beyond that they needs to be synchronized.

(Continue reading)

headers

Alex Eleftheriadis | 4 Dec 2008 11:05

Re: How to correctly group multiple source of the same media type when using layered codecs

The current thinking, exemplified in the draft RTP payload format for  
SVC, is that the SSRC values between the layers are identical. In  
various discussions between the editors and others we could not  
identify any drawbacks to this. If someone can think of one, now would  
be a good time to say so as the draft is nearing completion.

--Alex

On Dec 3, 2008, at 8:29 PM, Magnus Westerlund wrote:

> Hi,
>
> Another issue with layered codecs is how to determine which SSRC's in
> the different layers actually are part of the same source. The  
> immediate
> reaction is of course to use SDES cname mechanism and group the SSRC
> with the matching cname in each layer. That works as long as one  
> doesn't
> have more than one source (microphone, video camera, etc) in the same
> RTP session that needs to be synchronized.
>
> In the non-multilayered case this is not an issue, as each SSRC is
> providing a completely contained stream and encoding. But in the
> multilayered case you can get this:
>
>
> Layer a:
>
> SSRC X: CNAME=Charlie
> SSRC Y: CNAME=Charlie

(Continue reading)

headers

Magnus Westerlund | 4 Dec 2008 11:24

Re: How to correctly group multiple source of the same media type when using layered codecs

Alex Eleftheriadis skrev:
> The current thinking, exemplified in the draft RTP payload format for
> SVC, is that the SSRC values between the layers are identical. In
> various discussions between the editors and others we could not identify
> any drawbacks to this. If someone can think of one, now would be a good
> time to say so as the draft is nearing completion.
> 

RFC 3550 does say that it is the recommended behavior and I would argue
that it is mandatory to use this solution due to the raised issue.

I haven't seen a issue with using the same SSRC over all the layers.
What I am a bit concerned is the RFC 3550 text in section 8.3:

   For layered encodings transmitted on separate RTP sessions (see
   Section 2.4), a single SSRC identifier space SHOULD be used across
   the sessions of all layers and the core (base) layer SHOULD be used
   for SSRC identifier allocation and collision resolution.  When a
   source discovers that it has collided, it transmits an RTCP BYE
   packet on only the base layer but changes the SSRC identifier to the
   new value in all layers.

The issue I have is with the SHOULD use the core/base layer for
collision detection. If one has a codec that lacks base layer or allow
other codecs or payload types that is differently configured to use the
same RTP sessions one may end up with the case where an SSRC is not
first used in the core/base layer RTP session. Thus I would recommend
that one has detection in all layers and in case of collison applies the
change in all.

(Continue reading)

headers

Tina le Grand | 4 Dec 2008 17:11

Request comments on draft-legrand-rtp-isac-00.txt

I sent an email to the list a while ago, asking for comments on the Internet-Draft “draft-legrand-rtp-isac-00.txt” (http://www.ietf.org/internet-drafts/draft-legrand-rtp-isac-00.txt), but have not yet received any. I would highly appreciate to have the draft reviewed, all comments are welcome.

The draft is a description of the RTP Payload format for the iSAC wideband speech codec.

Best regards,

Tina le Grand.

Tina le Grand
R&D Manager, Stockholm
Global IP Solutions
http://www.gipscorp.com
Magnus Ladulåsgatan 63B | 118 27 Stockholm | Sweden
Phone: +46 8 410 398 03 | Mobile: +46 70 209 06 99

CONFIDENTIALITY NOTE: This e-mail message, including any attachment(s), contains information that may be confidential, protected by the attorney-client or other legal privileges, and/or proprietary non-public information. If you are not an intended recipient of this message or an authorized assistant to an intended recipient, please do not read, copy, use or disclose this communication and notify the sender immediately. It should be noted that any review, retransmission, dissemination or other use of, or taking action or reliance upon, this information by persons or entities other than the intended recipient is prohibited.

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

headers

Jonathan Lennox | 4 Dec 2008 17:59

Re: How to correctly group multiple source of the same media type when using layered codecs

I agree with your conclusion, that SSRC collision detection should be done on all the associated sessions,
and SSRCs should be changed everywhere if they collide anywhere.  I think this would technically require a
document updating 3550, but it's fairly minor.

The one concern I've had is if there could be codecs where it's possible for different session members to
(usefully) participate in non-overlapping subsets of the sessions.  In this case, cross-layer SSRC
collisions wouldn't be detected.  The question is whether this a) could happen, and b) would actually
matter.  (For instance, I would argue if a member isn't sending media, but is only providing RTCP feedback,
it doesn't.)

-- 
Jonathan Lennox
Vidyo, Inc
jonathan <at> vidyo.com

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund <at> ericsson.com]
> Sent: Thursday, December 04, 2008 5:25 AM
> To: Alex Eleftheriadis
> Cc: IETF AVT WG
> Subject: Re: [AVT] How to correctly group multiple source of the same
> media type when using layered codecs
> 
> Alex Eleftheriadis skrev:
> > The current thinking, exemplified in the draft RTP payload format for
> > SVC, is that the SSRC values between the layers are identical. In
> > various discussions between the editors and others we could not
> identify
> > any drawbacks to this. If someone can think of one, now would be a
> good
> > time to say so as the draft is nearing completion.
> >
> 
> RFC 3550 does say that it is the recommended behavior and I would argue
> that it is mandatory to use this solution due to the raised issue.
> 
> I haven't seen a issue with using the same SSRC over all the layers.
> What I am a bit concerned is the RFC 3550 text in section 8.3:
> 
> 
>    For layered encodings transmitted on separate RTP sessions (see
>    Section 2.4), a single SSRC identifier space SHOULD be used across
>    the sessions of all layers and the core (base) layer SHOULD be used
>    for SSRC identifier allocation and collision resolution.  When a
>    source discovers that it has collided, it transmits an RTCP BYE
>    packet on only the base layer but changes the SSRC identifier to the
>    new value in all layers.
> 
> The issue I have is with the SHOULD use the core/base layer for
> collision detection. If one has a codec that lacks base layer or allow
> other codecs or payload types that is differently configured to use the
> same RTP sessions one may end up with the case where an SSRC is not
> first used in the core/base layer RTP session. Thus I would recommend
> that one has detection in all layers and in case of collison applies
> the
> change in all.
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund <at> ericsson.com
> ----------------------------------------------------------------------
> _______________________________________________
> 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

headers

John Edward | 4 Dec 2008 20:27

Special Session on Audio/Video Transport

Special Session on Audio/Video Transport at HPCNCS-09: call for papers

There is a Special Session on Audio/Video Transport at the 2009 International Conference on High Performance Computing, Networking and Communication Systems (HPCNCS-09) (website: http://www.PromoteResearch.org ) that will be held during July 13-16 2009 in Orlando, FL, USA. We invite draft paper submissions. The conference will take place at the same time and venue where several other international conferences are taking place. The other conferences include:

· International Conference on Artificial Intelligence and Pattern Recognition (AIPR-09)

· International Conference on Automation, Robotics and Control Systems (ARCS-09)

· International Conference on Bioinformatics, Computational Biology, Genomics and Chemoinformatics (BCBGC-09)

· International Conference on Enterprise Information Systems and Web Technologies (EISWT-09)

· International Conference on Information Security and Privacy (ISP-09)

· International Conference on Recent Advances in Information Technology and Applications (RAITA-09)

· International Conference on Software Engineering Theory and Practice (SETP-09)

· International Conference on Theory and Applications of Computational Science (TACS-09)

· International Conference on Theoretical and Mathematical Foundations of Computer Science (TMFCS-09)

The website http://www.PromoteResearch.org contains more details.

Sincerely

John Edward

Publicity committee

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

19	May 2013
59	April 2013
53	March 2013
31	February 2013
31	January 2013
19	December 2012
49	November 2012
44	October 2012
22	September 2012
25	August 2012
46	July 2012
91	June 2012
53	May 2012
39	April 2012
92	March 2012
29	February 2012
18	January 2012
29	December 2011
108	November 2011
93	October 2011
83	September 2011
25	August 2011
77	July 2011
61	June 2011
67	May 2011
51	April 2011
91	March 2011
48	February 2011
143	January 2011
209	December 2010
234	November 2010
145	October 2010
96	September 2010
104	August 2010
123	July 2010
84	June 2010
95	May 2010
150	April 2010
243	March 2010
106	February 2010
179	January 2010
178	December 2009
72	November 2009
113	October 2009
148	September 2009
81	August 2009
132	July 2009
183	June 2009
237	May 2009
149	April 2009
163	March 2009
56	February 2009
75	January 2009
89	December 2008
129	November 2008
165	October 2008
187	September 2008
56	August 2008
191	July 2008
74	June 2008
50	May 2008
105	April 2008
86	March 2008
171	February 2008
104	January 2008
71	December 2007
104	November 2007
50	October 2007
70	September 2007
88	August 2007
151	July 2007
167	June 2007
103	May 2007
71	April 2007
108	March 2007
164	February 2007
176	January 2007
71	December 2006
138	November 2006
146	October 2006
73	September 2006
80	August 2006
105	July 2006
123	June 2006
141	May 2006
105	April 2006
181	March 2006
110	February 2006
89	January 2006
107	December 2005
118	November 2005
101	October 2005
99	September 2005
72	August 2005
149	July 2005
125	June 2005
84	May 2005
119	April 2005
91	March 2005
119	February 2005
150	January 2005
99	December 2004
109	November 2004
98	October 2004
154	September 2004
188	August 2004
190	July 2004
221	June 2004
176	May 2004
96	April 2004
73	March 2004
114	February 2004
65	January 2004
144	December 2003
191	November 2003
111	October 2003
108	September 2003
63	August 2003
116	July 2003
99	June 2003
82	May 2003
73	April 2003
161	March 2003
55	February 2003
138	January 2003
87	December 2002
122	November 2002
147	October 2002
35	September 2002
29	August 2002
122	July 2002
90	June 2002
100	May 2002
119	April 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31