Subject: RE: R: [AVT] CCMdraftreview-- should"bandwidth"includetheheaderoverhead

From: "Allison, Art" <[email-masked]>
Date: Fri, 23 Feb 2007 09:54:23 -0500

How to control lip-sync or lack thereof is clearly out of scope here.

However, I respectively disagree with the AD that it is out of scope as
a factor in the decision between selection of a total bit rate control
vs. a partial bit rate control.  

It is only one factor, but declaring it out of scope as a consideration
can be expected to impact the technical choice.  

I request reconsideration and clarification, as surly the AD did not
intend to force the group to ignore a technical factor that is material
to the RFC content.

_____________
Art Allison
Director, Advanced Engineering
Science & Technology
National Association of Broadcasters
1771 N Street, NW
Washington, D.C. 20036
Phone: 202.429.5418
Fax: 202.777.4981
[email-masked]

The National Association of Broadcasters is a trade association that
advocates on behalf of more than 8,300 free, local radio and television
stations and also broadcast networks before Congress, the Federal
Communications Commission and the Courts.

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Friday, February 23, 2007 4:12 AM
To: Desineni, Harikishan
Cc: Allison, Art; [email-masked]
Subject: Re: R: [AVT] CCMdraftreview--
should"bandwidth"includetheheaderoverhead

Hi,

I don't think this topic is really relevant for the TMMBR discussion. 
The issue you talk about arise independently of the existance of TMMBR
or not. Beyond how a media sender packetize data it can't make much to
affect the lip-synch (assuming a good implementation). RTP was designed
with a model that it is the receiver that needs to buffer and delay its
playout to ensure best possible synchronization and smooth playout. And
as I see it there are good reasons for this model. First any sender
adjusting model breaks down in multi-party sessions. Also the feedback
loop issues are eliminated by having the receiver deal with it.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 23 Feb 2007 17:22:14 +0200

Hi,
I think what Magnus is saying is that TMMBR address the bit rate of a specific stream, for example the video.
Now as for lip-synch problem. The assumption is that the sender will put the audio and video in its output buffer synchronizes enableing the receiver to adjuct based on time. The sender do not have any control on the way the medai handled by the network.
When a receiver aks for a TMMBR to reduce the bit rate, in some cases due to application constrains it is typicaly for the video. The sender can reduce the bit rate and keep the frame rate and this will keep the lip synch or it may reduce the frame rate and re-adjuct is internal synchronization between the audio and video keeping them synchronized on its output buffers.
So my view, for TMMBR, lip-synch is not related
Roni Even

________________________________

מאת: Allison, Art [mailto:[email-masked]]
נשלח: ו 23/02/2007 16:54
אל: Magnus Westerlund; Desineni, Harikishan
עותק לידיעה: [email-masked]
נושא: RE: R:[AVT] CCMdraftreview-- should"bandwidth"includetheheaderoverhead

_____________
Art Allison

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Friday, February 23, 2007 4:12 AM
To: Desineni, Harikishan
Cc: Allison, Art; [email-masked]
Subject: Re: R: [AVT] CCMdraftreview--

Hi,

Cheers

Magnus Westerlund

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 23 Feb 2007 09:31:29 -0800

I am addressing Art’s point on a point to point topology. A sender can react to TMMBR several ways as you pointed (changing frame rate, packet sizes etc,). The end result could be that packets are getting delayed or arriving too early at the receiver. This could happen due to variable size of video packets. Some video packets may experience longer delay than the corresponding audio packets or audio packets may experience more delay when they stay behind video over serial links (Guido’s draft).

My point is that a receiver could inform the sender about delayed or too early arrival of packets if it chooses to. This can be done with the help of a new RTCP message. A sender can (if it chooses to) make use of the delay/earliness information while adjusting its rate for each media. 

Regarding the feedback loop issue: 

What I am considering is another RTCP message for reporting delay when a receiver detects problem with packet arrivals. The performance of feedback is anyways dictated by the RTCP timing rules allowed by the RTP profile under use. This is applicable to any RTCP message.

Thanks,

Hari

From: Even, Roni [mailto:[email-masked]] 
Sent: Friday, February 23, 2007 7:22 AM
To: Allison, Art; Magnus Westerlund; Desineni, Harikishan
Cc: [email-masked]
Subject: RE: R:[AVT] CCMdraftreview-- should"bandwidth"includetheheaderoverhead

Hi,

Roni Even

_____________
Art Allison

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Friday, February 23, 2007 4:12 AM
To: Desineni, Harikishan
Cc: Allison, Art; [email-masked]
Subject: Re: R: [AVT] CCMdraftreview--

Hi,

Cheers

Magnus Westerlund

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 23 Feb 2007 13:51:38 -0500

Maybe the time adjustment draft, draft-taylor-avt-time-align-00.txt, 
would be an useful mechanism here. I plan to reissue it shortly.

Desineni, Harikishan wrote:
> I am addressing Art’s point on a point to point topology. A sender
> can react to TMMBR several ways as you pointed (changing frame rate,
> packet sizes etc,). The end result could be that packets are getting
> delayed or arriving too early at the receiver. This could happen due
> to variable size of video packets. Some video packets may experience
> longer delay than the corresponding audio packets or audio packets
> may experience more delay when they stay behind video over serial
> links (Guido’s draft).
> 
> 
> 
> My point is that a receiver could inform the sender about delayed or
> too early arrival of packets if it chooses to. This can be done with
> the help of a new RTCP message. A sender can (if it chooses to) make
> use of the delay/earliness information while adjusting its rate for
> each media.
> 
> 
> 
> What I am considering is another RTCP message for reporting delay
> when a receiver detects problem with packet arrivals. The performance
> of feedback is anyways dictated by the RTCP timing rules allowed by
> the RTP profile under use. This is applicable to any RTCP message.
> 
> 
> 
> Thanks,
> 
> Hari
> 
> 
> 
> From: Even, Roni [mailto:[email-masked]] Sent: Friday,
> February 23, 2007 7:22 AM To: Allison, Art; Magnus Westerlund;
> Desineni, Harikishan Cc: [email-masked] Subject: RE: R:[AVT]
> CCMdraftreview-- should"bandwidth"includetheheaderoverhead
> 
> 
> 
> Hi,
> 
> Now as for lip-synch problem. The assumption is that the sender will
> put the audio and video in its output buffer synchronizes enableing
> the receiver to adjuct based on time. The sender do not have any
> control on the way the medai handled by the network.
> 
> When a receiver aks for a TMMBR to reduce the bit rate, in some cases
> due to application constrains it is typicaly for the video. The
> sender can reduce the bit rate and keep the frame rate and this will
> keep the lip synch or it may reduce the frame rate and re-adjuct is
> internal synchronization between the audio and video keeping them
> synchronized on its output buffers.
> 
> מאת: Allison, Art [mailto:[email-masked]] נשלח: ו 23/02/2007 16:54 
> אל: Magnus Westerlund; Desineni, Harikishan עותק לידיעה: [email-masked]
>  נושא: RE: R:[AVT] CCMdraftreview--
> However, I respectively disagree with the AD that it is out of scope
> as a factor in the decision between selection of a total bit rate
> control vs. a partial bit rate control.
> 
> It is only one factor, but declaring it out of scope as a
> consideration can be expected to impact the technical choice.
> 
> intend to force the group to ignore a technical factor that is
> material to the RFC content.
> 
> _____________ Art Allison Director, Advanced Engineering Science &
> Technology National Association of Broadcasters 1771 N Street, NW 
> Washington, D.C. 20036 Phone: 202.429.5418 Fax: 202.777.4981 
> [email-masked]
> 
> advocates on behalf of more than 8,300 free, local radio and
> television stations and also broadcast networks before Congress, the
> Federal Communications Commission and the Courts.
> 
> -----Original Message----- From: Magnus Westerlund
> [mailto:[email-masked]] Sent: Friday, February 23,
> 2007 4:12 AM To: Desineni, Harikishan Cc: Allison, Art; [email-masked] 
>  The issue you talk about arise independently of the existance of
> TMMBR or not. Beyond how a media sender packetize data it can't make
> much to affect the lip-synch (assuming a good implementation). RTP
> was designed with a model that it is the receiver that needs to
> buffer and delay its playout to ensure best possible synchronization
> and smooth playout. And as I see it there are good reasons for this
> model. First any sender adjusting model breaks down in multi-party
> sessions. Also the feedback loop issues are eliminated by having the
> receiver deal with it.
> 
> Cheers
> 
> Magnus Westerlund
> 
>  Ericsson AB                | Phone +46 8 4048287 Torshamsgatan 23
> | Fax   +46 8 7575550 S-164 80 Stockholm, Sweden | mailto:
> [email-masked] 
> _______________________________________________ Audio/Video Transport
> Working Group [email-masked] https://www1.ietf.org/mailman/listinfo/avt
> 
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Feb 2007 11:40:09 +0100

> vs. a partial bit rate control.  

Can you please clarify what you mean with total vs partial bit-rate control.

> intend to force the group to ignore a technical factor that is material

To be clear, in AVT I am only another technical contributor. Cullen 
Jennings is the responsible AD for this WG. I am not trying to force 
something out. However I have so far failed to see how the issue you are 
discussing do affect TMMBR. Looking at the fundamental synchronization 
model RTP has, TMMBRs impact on lip-synch is purely implementation 
specific. Sure there are things that in the implementation that controls 
what is actually sent that could affect when packets get sent in such a 
way that it has some impact on the lip-synch. Are there any special part 
of the problem that you would like to have note about to help improve 
implementations?

Cheers

Magnus Westerlund