Subject: [clue] FW: New Version Notification fordraft-romanow-clue-audio-rendering-tag-00.txt

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 30 May 2012 22:03:50 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 30, 2012 10:02 PM
To: Allyn Romanow (allyn)
Cc: [email-masked]; Robert Hansen (rohanse2); Brian Baldino (bbaldino)
Subject: New Version Notification fordraft-romanow-clue-audio-rendering-tag-00.txt

A new version of I-D, draft-romanow-clue-audio-rendering-tag-00.txt has been successfully submitted by Allyn Romanow and posted to the IETF repository.

Filename:	 draft-romanow-clue-audio-rendering-tag
Revision:	 00
Title:		 The need for audio rendering tag mechanism in the CLUE Framework
Creation date:	 2012-05-31
WG ID:		 Individual Submission
Number of pages: 8

Abstract:
   The purpose of this draft is for discussion in the CLUE working
   group.

   It proposes adding an audio rendering tag to the CLUE framework
   [I-D.ietf-clue-framework], which makes it possible for the consumer
   to correctly render audio with respect to video in a multistream
   video conference.  The solution proposed is in partial response to
   CLUE Task #10, Does Framework provide sufficient info for receiver?

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 May 2012 13:27:23 -0400

I'm really happy to see drafts such as this one and the others sent out 
at the same time. They really communicate a lot of thinking and really 
help to facilitate conversation.

I do have some basic questions about the functionality proposed in this 
draft. (Note that I'm not well versed in media processing, so I won't 
feel bad to be told that my questions make no sense.)

IIUC, RTP (together with some basic signaling in SDP) has a mechanism to 
specify lip-sync, based on matching CNAME values between an audio and 
video stream. Why is the lip-sync mechanism not sufficient for the 
consumer to match a particular packet from an audio capture to the 
screen(s) that displayed recent video packets?

I do see a different but related problem that I don't think has been 
addressed yet: how do I ensure that I have selected the proper set of 
audio captures that will carry the audio corresponding to the set of 
video captures that I have selected?

	Thanks,
	Paul

On 5/31/12 1:03 AM, Allyn Romanow (allyn) wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Robert Hansen <[email-masked]>
Date: Thu, 31 May 2012 18:51:07 +0100

Hi Paul,

As you say, CNAME is used for lipsyncby establishing which RTP streams 
share a common clock.

However, in multistream there may be a more granular positional 
association than just this synchronisation. For instance, in a case 
where an endpoint produces three video streams and one audio stream, all 
four streams would likely share a common clock and hence can be 
sychronised. However, at any given time the audio may come from one of 
three microphones associated with the three positions, and hence at the 
far end we would want it to be played out in that position.

RTCP SDES packets also has the property that they are not received as 
frequently or in sync with the RTP media packets; this isn't a 
particular problem for lipsync, as the adjustments required to sync 
streams are generally small and in the case of audio can be concealed in 
moments of silence. However, starting to play out audio from one speaker 
and then moving it a few seconds later when the SDES packet arrives is 
much more noticeable to users.

Rob

On 31/05/2012 18:27, Paul Kyzivat wrote:
>> Subject: New Version Notification
>> fordraft-romanow-clue-audio-rendering-tag-00.txt
>>
>> A new version of I-D, draft-romanow-clue-audio-rendering-tag-00.txt
>> has been successfully submitted by Allyn Romanow and posted to the
>> IETF repository.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 May 2012 14:17:02 -0400

> As you say, CNAME is used for lipsyncby establishing which RTP streams

Is the CNAME used for this always derived from the SSRC, or can it be 
derived from a CSRC?

> far end we would want it to be played out in that position.

In such a case, couldn't the provider use three different CSRCs to 
indicate which mic was being sent? Or use three different SSRCs for that 
purpose, if necessary to identify the correlation.

> much more noticeable to users.

I had assumed that the SSRC:CNAME correlation was cached. If so, I would 
think this wouldn't normally be a problem.

The point of my question is just to see if there is a way to use 
existing mechanisms rather than invent new ones.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Thu, 31 May 2012 23:12:31 +0300

Hi,
I think that Magnus has a more general proposal in
http://tools.ietf.org/id/draft-westerlund-avtext-rtcp-sdes-srcname-00.txt 
Roni Even

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Allyn Romanow (allyn)
> Sent: Thursday, May 31, 2012 8:04 AM
> To: CLUE
> Subject: [clue] FW: New Version Notification fordraft-romanow-clue-
> audio-rendering-tag-00.txt
> 
> 
> 
> A new version of I-D, draft-romanow-clue-audio-rendering-tag-00.txt has
> been successfully submitted by Allyn Romanow and posted to the IETF
> repository.
>