Subject: [AVT] WGLC on draft-ietf-avr-acpf-ccm-03

From: "Even, Roni" <[email-masked]>
Date: Mon, 11 Dec 2006 15:20:10 +0200

Hi,
In section 4.3.4.2 you discuss the need for RTP payload type for VBCM and mention it is not needed for FIR and TSTS and I assume you also mean for TMMBR.
I am not sure I understand the argument. Video can be multiplexed and the identification of each stream is based on the SSRC. So if a receiver wants to ask for FIR it applies to a specific SSRC from the sender, or am I missing something. 

Thanks
Roni

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

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 21 Dec 2006 06:33:23 +0200

Hi Roni, all,

Magnus and I had long discussions on this topics when adding the PT  
field in the first place.   The PT is in the VBCM message to be  
future proof against rather exotic scenarios, not used in any designs  
I'm aware of.  Our discussion was about over-engineering and spending  
bits on the wire vs. future proof and robustness.  At the end we  
settled for the latter.  For TMMBR, FIR, and TSTR, we haven't seen a  
need, as discussed below.

For everyone's reference, here is the remark in question.   The  
context is the introduction of a PT field in the VBCM message, which  
is not in the Full Intra Request, Temporal-spatial tradeoff, and  
TMMBR message types (and their respective reverse messages, when  
available).

      Note: There has been some discussion whether the payload type  
field
      in this message is needed.  It would be needed if there were
      potentially more than one VBCM-capable RTP payload types in the
      same session, and that the semantics of a given VBCM message
      changes from PT to PT.  This appears to be the case.  For example,
      the picture identification mechanism in messages of H.271 type  
0 is
      fundamentally different between H.263 and H.264 (although both use
      the same syntax.  Therefore, the payload field is justified here.
      It was further commented that for TSTS and FIR such a need does  
not
      exist, because the semantics of TSTS and FIR are either loosely
      enough defined, or generic enough, to apply to all video payloads
      currently in existence/envisioned.

On Dec 11, 2006, at 3:20 PM, Even, Roni wrote:

> Hi,
> In section 4.3.4.2 you discuss the need for RTP payload type for  
> VBCM and mention it is not needed for FIR and TSTS and I assume you  
> also mean for TMMBR.
> I am not sure I understand the argument. Video can be multiplexed  
> and the identification of each stream is based on the SSRC. So if a  
> receiver wants to ask for FIR it applies to a specific SSRC from  
> the sender, or am I missing something.

First, why is TMMBR not mentioned here?  TMMBR controls the bandwidth  
per sender in a given session, regardless what PT(s) -- yes,  
potentially more than one PT -- are used by this sender in the given  
session.  Since TMMBR is completely opaque to the payload itself --  
it only controls bandwidth -- there is no need to indicate PTs.

With respect to the video-specific messages (VBCM, TSTR, FIR):

It is conceivable that multiple payload types are used by a single  
sender in a single session.  I'm not talking about using PT as a  
demux point to distinguish between different packet streams, I'm  
talking about the analogous of interleaving G.711 and DTMF (with  
different payload types) by the same sender and in the same session.   
This is, AFAIK, not a scenario used in practice today.  However, it  
is something that may happen in the future.

To be future-proof against those scenarios, it appears sensible to  
spend bits on the wire to signal the PT for those message types where  
the semantics of the message changes with PT.  This is the case for  
VBCM, but not for FIR and TSTR.  In other words, the semantics of  
both FIR and TSTR are independent of the PT and applicable to all  
video payload formats we are aware of.  VBCM is not.  And that's why  
the PT is in there.

Clearer?  Do we need additional text in the note cited above?  Would  
you care to propose text?

Regards,
Stephan

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 21 Dec 2006 09:04:30 +0200

Stephan,

I am still not sure I understand the scenario. 

If I have two video streams multiplexed, each having a separate PT and different SSRC, for example a video stream of the room from the camera and a video representing a presentation. (H.239). I will need to control the rate of the separate streams (lower one and raise the rate of the other) and I may need to update (FIR) one of them based on a video switch of one of them. Will this work without specifying the PT in the FIR or TMMBR

Roni

________________________________

From: Stephan Wenger [mailto:[email-masked]] 
Sent: Thursday, December 21, 2006 6:33 AM
To: Even, Roni
Cc: [email-masked]
Subject: Re: [AVT] WGLC on draft-ietf-avr-acpf-ccm-03

Hi Roni, all,

Magnus and I had long discussions on this topics when adding the PT field in the first place.   The PT is in the VBCM message to be future proof against rather exotic scenarios, not used in any designs I'm aware of.  Our discussion was about over-engineering and spending bits on the wire vs. future proof and robustness.  At the end we settled for the latter.  For TMMBR, FIR, and TSTR, we haven't seen a need, as discussed below.

For everyone's reference, here is the remark in question.   The context is the introduction of a PT field in the VBCM message, which is not in the Full Intra Request, Temporal-spatial tradeoff, and TMMBR message types (and their respective reverse messages, when available).

     Note: There has been some discussion whether the payload type field

     the picture identification mechanism in messages of H.271 type 0 is

     It was further commented that for TSTS and FIR such a need does not

Hi,

First, why is TMMBR not mentioned here?  TMMBR controls the bandwidth per sender in a given session, regardless what PT(s) -- yes, potentially more than one PT -- are used by this sender in the given session.  Since TMMBR is completely opaque to the payload itself -- it only controls bandwidth -- there is no need to indicate PTs.

It is conceivable that multiple payload types are used by a single sender in a single session.  I'm not talking about using PT as a demux point to distinguish between different packet streams, I'm talking about the analogous of interleaving G.711 and DTMF (with different payload types) by the same sender and in the same session.  This is, AFAIK, not a scenario used in practice today.  However, it is something that may happen in the future.  

To be future-proof against those scenarios, it appears sensible to spend bits on the wire to signal the PT for those message types where the semantics of the message changes with PT.  This is the case for VBCM, but not for FIR and TSTR.  In other words, the semantics of both FIR and TSTR are independent of the PT and applicable to all video payload formats we are aware of.  VBCM is not.  And that's why the PT is in there.

Clearer?  Do we need additional text in the note cited above?  Would you care to propose text?

Regards,

Stephan

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Dec 2006 10:15:44 +0100

> If I have two video streams multiplexed, each having a separate PT and different SSRC, for example a video stream of the room from the camera and a video representing a presentation. (H.239). I wil…

Please remember that the sources are identified using SSRC. However I
think we need to fix the text of the SSRC field for FIR, it is not
particular clear. It is the Media sender to which the FIR applies that 
is included in the FCI.

Thus in the above scenario a media receiver sending a FIR to the 
document camera, inlcudes the SSRC of the document camera to tell it 
that this FIR applies to it.

In regards to TMMBR. The same is true here, the SSRC indicate who it 
applies to. The message applies to a particular SSRC and the payload 
type used has no importance for requesting that sender to conform to the 
request. In fact it is not totally unlikely that a TMMBR could result in 
a PT change to enable the sender to change its bit-rate.

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]
----------------------------------------------------------------------

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 21 Dec 2006 11:19:30 +0200

Magnus,
Thanks, this was also my understanding of the usage of SSRC. I gave this example since I am not sure I understand the use case for PT in VBCM, is it suggesting some multiplexing which will have different PT but same SSRC?
Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, December 21, 2006 11:16 AM
> To: Even, Roni
> Cc: Stephan Wenger; [email-masked]
> > If I have two video streams multiplexed, each having a separate PT and
> different SSRC, for example a video stream of the room from the camera and
> a video representing a presentation. (H.239). I will need to control the
> rate of the separate streams (lower one and raise the rate of the other)
> and I may need to update (FIR) one of them based on a video switch of one
> of them. Will this work without specifying the PT in the FIR or TMMBR
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Dec 2006 10:24:43 +0100

> Thanks, this was also my understanding of the usage of SSRC. I gave this example since I am not sure I understand the use case for PT in VBCM, is it suggesting some multiplexing which will have dif…

In regards to the VBCM and the PT case. The primary concern is that some 
VBCM shall only be interpreted in the context of a specific payload 
type. This could for example exist if the values of some type of 
feedback is dependent on for example a dynamic table from the sender. In 
that case one could provide the wrong feedback if a payload type switch 
has happened between the time of the feedback was generated and 
received. Thus this is really only a safety net to detect corner cases.

Cheers

Magnus Westerlund