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

From: "Kalleitner, Franz" <[email-masked]>
Date: Mon, 8 Jan 2007 13:28:51 +0100

stefan,
please find some comments and questions below.
 
kind regards,
franz

ch 2.2.Terminology

about the Decoder Refresh Point: 
does it concern the size of the access unit? imagine, an I(DR)-frame will be send after the FIR
request has been received. based on which criteria the sending application 
can decide to send an  IDR frame i.e. the base layer only ? including enhancement layers?

a comment about stream thinning:
right, stream thinning is tricky. however, for scaling purposes it will reduce
processing power and memory consumption sustainable (compared to video transcoding).

ch 3.2
As far as I remember the IETF work on megaco has been shifted to ITU.
in fact, the quoted rfc3525 does not include enhancements specified since than.

ch 4.3.2 TSTR
I wonder a node will not "own" a temporal-spatial tradeoff in case of multicast?
In fact, if multiple receivers sends an TSTR request, which (at most 31 possibilities) will be
selected by the media sender ? based on which criteria? If no receiver can "own" a trade off, 
the trade-off might be switched arbitrarily every time a new request will be received. 
For video consumers it must be annoying if the quality will change consecutive.
This solution is specified for TMMBR and might be useful for TSTR too.

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

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 8 Jan 2007 16:03:31 +0200

Hi Franz,
looks like the SVC community wakes up :-)  Comments inline.
Stephan

On Jan 8, 2007, at 2:28 PM, Kalleitner, Franz wrote:

> does it concern the size of the access unit?

I don't understand the question.

> imagine, an I(DR)-frame will be send after the FIR

Out of scope of this spec, as being payload specific.  Up to the  
implementation and/or RTP payload specs.  We could define the term  
"Decoder Refresh Point" in the SVC spec -- or let JVT define it and  
be done.

> processing power and memory consumption sustainable (compared to  

Correct.  Do you think there is any action required in the document?   
I guess, your statement is pretty obvious, and not critical for  
interoperability.

> in fact, the quoted rfc3525 does not include enhancements specified  

Again correct.  However, that does not make the statement in the  
draft incorrect.  Even the ITU-T has -- up to today -- not defined a  
MEGACO package that fulfills the role mentioned.

> selected by the media sender ?

Any of them, as stated in the draft.  Quoted from section 3.5.2.:

The use of TSTR and TSTA in multipoint scenarios is a non-trivial  
subject, and can be solved in many implementation-specific ways.  
Problems are stemming from the fact that TSTRs will typically arrive  
unsynchronized, and may request different trade-off values for the  
same stream and/or endpoint encoder.  This memo does not specify a  
MCU’s or endpoint’s reaction to the reception of a suggested trade- 
off as conveyed in the TSTR -- we only require the receiver of a TSTR  
message to reply to it by sending a TSTA, carrying the new trade-off  
chosen by its own criteria (which may or may not be based on the  
trade-off conveyed by TSTR).  In other words, the trade-off sent in  
TSTR is a non-binding recommendation; nothing more.

> based on which criteria?

Undefined and implementation specific.  See above.

> If no receiver can "own" a trade off,

Correct, a stupid implementation may do so.

> For video consumers it must be annoying if the quality will change  

Correct, but less stupid implementations will not do so.  Something  
along the lines of TSTR is available in H.245 for many years, and  
those who implement products know how to deal with it.

> This solution is specified for TMMBR and might be useful for TSTR too.

It wouldn't work.  TMMBR works by assigning "ownership" always to the  
most restrictive request (unless in certain corner cases).  That  
makes sense, because it's better (from a network and congestion  
viewpoint) to follow a conservative approach and give preference to  
the lowest bandwidth requirement.  If you translate that to TSTR,  
which would you favor: lower frame rate or lower spatial quality?   
And how are you sure that I have the same preferences as you have?   
Besides, having this complex mechanism would be overkill for a non- 
binding recommendation.

Regards,
Stephan

---

From: "Kalleitner, Franz" <[email-masked]>
Date: Tue, 9 Jan 2007 08:58:04 +0100

stephan,
 
thanks for your reply. comments inline, see [FK]

br, franz 

________________________________

Von: Stephan Wenger [mailto:[email-masked]]
Gesendet: Mo 08.01.2007 15:03
An: Kalleitner, Franz
Cc: [email-masked]
Betreff: Re: AW: [AVT] WGLC on draft-ietf-avr-acpf-ccm-03

Hi Franz, 
 
[FK] do they?   ;-)
 
Stephan

	stefan,

	kind regards,
	franz

	ch 2.2.Terminology

Out of scope of this spec, as being payload specific.  Up to the implementation and/or RTP payload specs.  We could define the term "Decoder Refresh Point" in the SVC spec -- or let JVT define it and be done.
 
[FK] well, both SVC spec and JVT might be a proper place

Correct.  Do you think there is any action required in the document?  I guess, your statement is pretty obvious, and not critical for interoperability.
[FK]  reflecting SVC,  the number of TMMBR feedbacks could be reduced, do they ? 

	ch 3.2

Again correct.  However, that does not make the statement in the draft incorrect.  Even the ITU-T has -- up to today -- not defined a MEGACO package that fulfills the role mentioned.
 
[FK]  no it doesn't. concerning physically decomposited MCU, isn't that covered by H248.19 ?
 
ch 4.3.2 TSTR

The use of TSTR and TSTA in multipoint scenarios is a non-trivial subject, and can be solved in many implementation-specific ways. Problems are stemming from the fact that TSTRs will typically arrive unsynchronized, and may request different trade-off values for the same stream and/or endpoint encoder.  This memo does not specify a MCU's or endpoint's reaction to the reception of a suggested trade-off as conveyed in the TSTR -- we only require the receiver of a TSTR message to reply to it by sending a TSTA, carrying the new trade-off chosen by its own criteria (which may or may not be based on the trade-off conveyed by TSTR).  In other words, the trade-off sent in TSTR is a non-binding recommendation; nothing more.
 
[FK]  OK

	based on which criteria? 

Correct, but less stupid implementations will not do so.  Something along the lines of TSTR is available in H.245 for many years, and those who implement products know how to deal with it.

It wouldn't work.  TMMBR works by assigning "ownership" always to the most restrictive request (unless in certain corner cases).  That makes sense, because it's better (from a network and congestion viewpoint) to follow a conservative approach and give preference to the lowest bandwidth requirement.  If you translate that to TSTR, which would you favor: lower frame rate or lower spatial quality?  And how are you sure that I have the same preferences as you have?  Besides, having this complex mechanism would be overkill for a non-binding recommendation.
 
[FK]  I see, different preferences is a good counter-argrument ...

Regards,
Stephan

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 9 Jan 2007 14:43:17 +0200

Answers/Comments  inline, only on those areas where there still be  
open questions (rest removed).
Stephan

On Jan 9, 2007, at 9:58 AM, Kalleitner, Franz wrote:

> [...]
> Correct.  Do you think there is any action required in the  
> document?  I guess, your statement is pretty obvious, and not  
> critical for interoperability.

When to send TMMBR, and with what values, is entirely up to the  
application (subject to AVPF timing rules and the provisions  
mentioned in CCM, of course).  A well-designed SVC receiver may or  
may not find it convenient or necessary to send a larger number of  
TMMBR messages compared to a non-SVC receiver.  The case could be  
made that, since it is easy for an SVC sender to react to bandwidth  
reduction (compared to non-scalable codecs), it's wise to send more.   
The opposite case can equally be made -- chances are that congestion  
losses do not affect an SVC stream as much as a non-scalable stream,  
and therefore we don't need TMMBR at all (and just use regular RTCP  
RRs for quality control).
However, this whole subject is not getting us anywhere.  TMMBR is  
payload agnostic, and we should not add text to the opposite, unless  
there is a truly compelling reason.

> draft incorrect.  Even the ITU-T has -- up to today -- not defined  
> a MEGACO package that fulfills the role mentioned.
>

H.248.19, to the best of my knowledge, does not include functionality  
as discussed.  It could perhaps be added.  I may be slightly out of  
synch here, but last time I looked, .19's functionality was  
rudimentary at best :-)

> [...]

---

From: "Kalleitner, Franz" <[email-masked]>
Date: Wed, 10 Jan 2007 07:53:04 +0100

done
 
br, franz

Von: Stephan Wenger [mailto:[email-masked]]
Gesendet: Di 09.01.2007 13:43
An: Kalleitner, Franz
Cc: [email-masked]
Betreff: Re: AW: AW: [AVT] WGLC on draft-ietf-avt-avpf-ccm-03