Re: [AVT] draft-ietf-avt-rtp-svc-07.txt: classical RTPDecodingOrder Recovery Mode

[Randell Jesup <rjesup at wgate.com>]

"Thomas Schierl" <schierl at hhi.fhg.de> writes:
>Randell Jesup [mailto:rjesup at wgate.com] writes:
>> "Thomas Schierl" <schierl at hhi.fhg.de> writes:
>> >The main target for session multiplexing will be layered multicast
>> e.g. over
>> >a wireless broadcast/multicast channel as DVB-H. In that case somebody
>> may
>> >rely or may not rely on the frame rate. Anyway, when having SVC
>> conformance
>> >in mind, a session carrying an enhancement layer must have or must
>> enhance a
>> >lower session to the same or a higher frame rate than contained in the
>> lower
>> >session.
>>
>> Ok, though that just says that a major use of this will do that.
>
>Yes, and it further says that we may not need to cover the case described by
>Yann. And so, we may end the "frame rate discussion".

But I disagree with that as a requirement for SVC:  Why must an enhancement
layer have the same or higher frame rate?  Even ignoring the
non-continuous/variable framerate issues (and they exist too), I would
think that there would be use for something like a 60Hz SD layer with
a 24Hz hi-resolution layer.  I'm not sure of that, though.

But this is straying from my main point, which is you need to consider (or
mandate no use of) variable framerates and skipping during encoding.

>> Important
>> to remember, but as with most protocols it's better to not tie it too
>> closely to one particular application.
>
>Sure, the current approach (section 8.1.1 in draft-ietf-avt-rtp-svc-07.txt)
>is supporting all use cases.

This is where my not following the details of the draft hurts me.  I'll try
to catch up.  8.1.1. mandates no use of CL-DON.

BTW, typo in 8.1.1: "decdoding oreder"

>> >Another point: If we are talking about telephony, we typically do not
>> have
>> >frames with decoding order different from presentation order. This is
>> due to
>> >the mentioned delay constraints.
>>
>> Face-to-Face Video Telephony normally wouldn't run CL-DON type modes,
>> true.  However other applications with variable frame rate would, for
>> example security cameras, and not every source of a video signal is a
>> fixed-framerate capture device; the "video" could be an
>> algorithmically-generated visual stream, for example for visualization
>> uses, and scalability might be very useful there when the receivers
>> (power or bandwidth) vary, or if it's a conference.
>
>Why should CL-DON be run by use cases different from video telephony? I do
>not see the point. The discussion is about "why do we need CL-DON, when
>8.1.1 covers all cases?" The slides, sent out by Yann yesterday, show that
>even in packet loss scenarios 8.1.1 works.

Since I'm not up to speed on 8.1.1 (which, BTW, is still more than a bit
confusing, even with the example), I can't comment, other than to say that
no solution should require 'fixed' framerates, and I don't think (but am
not 100% sure) that higher layers should be *required* to have same or
higher framerates than lower layers.

-- 
Randell Jesup
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
http://www.ietf.org/mailman/listinfo/avt