Internet-Drafts | 1 Dec 21:00 2008
Picon

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

Tom Taylor | 2 Dec 04:27 2008

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)

Internet-Drafts | 2 Dec 20:15 2008
Picon

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

Magnus Westerlund | 3 Dec 19:19 2008
Picon

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)

Magnus Westerlund | 3 Dec 19:29 2008
Picon

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)

Alex Eleftheriadis | 4 Dec 11:05 2008

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)

Magnus Westerlund | 4 Dec 11:24 2008
Picon

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)

Tina le Grand | 4 Dec 17:11 2008

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
Jonathan Lennox | 4 Dec 17:59 2008

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

John Edward | 4 Dec 20:27 2008
Picon

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

Gmane