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

From: "Even, Roni" <[email-masked]>
Date: Sun, 7 Jan 2007 15:09:29 +0200

Magnus,
I think the reason you gave will also work for all feedback messages.
Example for FIR, if the encoder changed the stream it already did send a full picture so he will know that there is no need for it again, and that the request is old.
Also spatial tradeoff may be relevant to a specific PT
Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, December 21, 2006 11:25 AM
> To: Even, Roni
> Cc: Stephan Wenger; [email-masked]
> Subject: Re: [AVT] WGLC on draft-ietf-avr-acpf-ccm-03
> 
> Even, Roni skrev:
> > 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?
> 
> 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
> 
> 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: Stephan Wenger <[email-masked]>
Date: Mon, 8 Jan 2007 13:08:00 +0200

Not Magnus here, but...

> I think the reason you gave will also work for all feedback messages.

Certainly not for TMMBR, which handles an RTP packet stream and is  
totally opaque to different PTs in that stream (if any).

> Example for FIR, if the encoder changed the stream it already did  
> send a full picture so he will know that there is no need for it  
> again, and that the request is old.

Once more, we don't assume PT to be used as a multiplexing  
mechanism.  We are talking about ONE sender, which replaces codecs on  
the fly.  Which is not a practical use case (for video) at present,  
but is possible within the RTP spec space.  If something would break  
when we were not supporting this use case, our spec would be buggy.

In case of VBCM something breaks.  An H.271 VBCM with an H.271  
payloadType of 1 has a different meaning for H.263 than for H.264.   
For VBCM, we need to tell the receiver of FIR how to interpret the  
message -- is it the H.263 or the H.264 interpretation -- since the  
PT may have changed during the RTT of the VBCM transmission. So we  
need to tell the receiver of FIR (the system which has both H.263 and  
H.264 encoders and perhaps changes them on the fly) what  
interpretation to use.
Are we in agreement here?

So why do we NOT need this for FIR?  The reaction to FIR is to send a  
Decoder Refresh Point.  Whatever that means in the respective codec  
spec.  It's abstract.  So we don't need to distinguish between codec  
types: FIR is FIR.  The reaction to FIR is to send a Decoder Refresh  
Point at the earliest possible time.  The sender does that using  
whatever codec it chooses.

Same reasoning for TSTR.

What would be the value if we were adding a PT field to the FIR and  
TSTR messages?  You could express something like "Dear encoder, send  
a Decoder Refresh Point at the earliest possible time, but only if  
you currently use H.263.  If you use something else,, you don't need  
to."  This is NOT what FIR wants to express from a use case  
perspective -- FIR aims at ensuring the unconditional sending of a  
Decoder Refresh Point (subject only to congestion control and pre- 
recorded content constraints).

With TSTR, adding the PT field could make a bit more sense, as there  
may be a value in signaling different tradeoffs for different  
codecs.  Almost certainly there would be a value of TSTR would not be  
so abstractly defined.  However, once more I do NOT see a need from a  
protocol functionality level -- nothing breaks of we don't have a  
PT.  If you see a compelling use case for different TSTs for  
different codecs, please let us know.

Regards,
Stephan

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 8 Jan 2007 13:23:06 +0200

Stephan,
OK
Roni

> From: Stephan Wenger [mailto:[email-masked]]
> Sent: Monday, January 08, 2007 1:08 PM
> To: Even, Roni
> Cc: Magnus Westerlund; [email-masked]
---------------------------------------------------------------------
> >> -
---------------------------------------------------------------------
> >> -
---------------------------------------------------------------------
> >> -