Subject: Re: [AVT] draft-ietf-avt-rtp-svc-07.txt: classical RTP Decoding Order Recovery Mode

From: "LEPROVOST YANN" <[email-masked]>
Date: Mon, 4 Feb 2008 17:12:50 +0100

Dear moderators,

Here is the presentation, following previous mail, detailing the
proposed method based on frame rates knowledge for the classical RTP
decoding order recovery proce <<RTP_SVC_decoder.ppt>> ss
 
Regards 

Yann Leprovost
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Tue, 05 Feb 2008 18:59:09 -0500

>decoding order recovery proce <<RTP_SVC_decoder.ppt>> ss

One problem I have with this scheme (and I haven't analyzed it deeply):
Framerate is often not a constant.

You can have frame 1 at time 0, frame 2 at time 3000, frame 3 at time
10000, frame 4 at time 12250, etc. 

A cursory viewing of your powerpoint implies that at least one method you
have requires known/constant framerates.

-- 
Randell Jesup
"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)

---

From: "LEPROVOST YANN" <[email-masked]>
Date: Wed, 6 Feb 2008 09:59:23 +0100

I am not sure of the time you refer to... 
Timestamps included in RTP packet header are derived from the frame sampling times at the emitter, that is, the sequence of TS values (in display order) reproduces the sampling instants of the video sensor. 
As I have not heard of any system using non constant sampling period (at least in mobile TV applications), I assume that the sequence of TS in display order should reproduce a constant frame rate. 

Regards 

Yann
-----Message d'origine-----
De : Randell Jesup [mailto:[email-masked]] 
Envoyé : mercredi 6 février 2008 00:59
À : LEPROVOST YANN
Cc : [email-masked]
Objet : Re: [AVT] draft-ietf-avt-rtp-svc-07.txt: classical RTP Decoding Order Recovery Mode

You can have frame 1 at time 0, frame 2 at time 3000, frame 3 at time 10000, frame 4 at time 12250, etc. 

A cursory viewing of your powerpoint implies that at least one method you have requires known/constant framerates.

--
Randell Jesup
"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)

---

From: <[email-masked]>
Date: Wed, 6 Feb 2008 14:10:45 +0200

Hi Yann, Randell, all,

I concur with Randell, as I mentioned in yesterday's conference call. In my understanding, the method finally specified should be generic and be able to handle any situation, including non-constant frame rate, packet losses, etc. 

In video telephony and video conferencing applications, as well other applications that requires low end-to-end delay and relatively smooth bitrate, the rate control algorithm in the encoder may frequently drop some frames, thus lead to non-constant frame rate. 

BR, YK 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext LEPROVOST YANN
>Sent: Wednesday, February 06, 2008 10:59 AM
>To: Randell Jesup
>Cc: [email-masked]
>Subject: Re: [AVT] draft-ietf-avt-rtp-svc-07.txt: classical 
>RTP DecodingOrder Recovery Mode
>
>
>Timestamps included in RTP packet header are derived from the 
>frame sampling times at the emitter, that is, the sequence of 
>TS values (in display order) reproduces the sampling instants 
>of the video sensor. 
>As I have not heard of any system using non constant sampling 
>period (at least in mobile TV applications), I assume that the 
>sequence of TS in display order should reproduce a constant 
>frame rate. 
>
>Regards 
>
>Yann
>De : Randell Jesup [mailto:[email-masked]] Envoyé : mercredi 
>6 février 2008 00:59 À : LEPROVOST YANN Cc : [email-masked] 
>You can have frame 1 at time 0, frame 2 at time 3000, frame 3 
>at time 10000, frame 4 at time 12250, etc. 
>
>A cursory viewing of your powerpoint implies that at least one 
>method you have requires known/constant framerates.
>
>--
>Randell Jesup
>"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."

---

From: Randell Jesup <[email-masked]>
Date: Wed, 06 Feb 2008 07:40:02 -0500

<[email-masked]> writes:
>I concur with Randell, as I mentioned in yesterday's conference call. In
>my understanding, the method finally specified should be generic and be
>able to handle any situation, including non-constant frame rate, packet
>losses, etc.
>
>In video telephony and video conferencing applications, as well other
>applications that requires low end-to-end delay and relatively smooth
>bitrate, the rate control algorithm in the encoder may frequently drop
>some frames, thus lead to non-constant frame rate.

In addition to dropped frames (constant capture rate with some frames not
encoded, which is most certainly used today), some "video" applications
might capture based on an external event (light flash as a random example,
or movement, or external physical trigger).  Also instead of traditional
"looping" cameras (which capture images continuously at a fairly constant
rate) you could have sensors or non-optical-sensor sources that can sample
or create an image on demand, so you might grab samples as fast as you
could encode them, leading to a highly variable rate.  

>LEPROVOST YANN wrote:

Mobile TV might have a constant framerate (like regular analog TV, which
has a constant rate by design), but there's no reason Mobile TV couldn't
drop frames either to manage bandwidth or to manage encoder or decoder
complexity (i.e. drop a frame so you have twice as long to encode or decode
the frame).

SVC needs to handle the needs of non-TV applications, such as video
conferencing.  It would allow a conference to support multiple resolutions
at the same time without requiring a high-cost/complexity MCU to transcode
streams.  There are other reasons variable rate needs to be handled as well.

-- 
Randell Jesup
[email-masked]

---

From: "Thomas Schierl" <[email-masked]>
Date: Wed, 6 Feb 2008 14:20:19 +0100

Ye-Kui,

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.

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. And, that of course should make the RTP
re-ordering process in case of packet loss much easier to implement, since
timestamp order is equal to decoding order. Anyway, currently we are talking
about native RTP mechanisms. Since there is no interleaving in the sessions,
these mechanisms should perfectly work without the need of any additional
indicators for decoding order.

Thomas

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, February 06, 2008 1:11 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [AVT] draft-ietf-avt-rtp-svc-07.txt: classical RTP
> DecodingOrder Recovery Mode
>
>
> Hi Yann, Randell, all,
>
> I concur with Randell, as I mentioned in yesterday's conference call.
> In my understanding, the method finally specified should be generic and
> be able to handle any situation, including non-constant frame rate,
> packet losses, etc.
>

----
Visit us at

GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February 2008 / Broadcast Mobile Convergence Forum / Booth 2B82
http://www.mobileworldcongress.com/homepage.htm

OFC 2008 / San Diego, California, USA / 26 - 28 February 2008 / Booth 411/415
http://www.ofcnfoec.org
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Wed, 06 Feb 2008 09:55:33 -0500

>lower session to the same or a higher frame rate than contained in the lower

Ok, though that just says that a major use of this will do that.  Important
to remember, but as with most protocols it's better to not tie it too
closely to one particular application.

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

---

From: "Thomas Schierl" <[email-masked]>
Date: Wed, 6 Feb 2008 16:30:24 +0100

Randell Jesup [mailto:[email-masked]] writes:
> 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".

> Important

Sure, the current approach (section 8.1.1 in draft-ietf-avt-rtp-svc-07.txt)
is supporting all use cases.

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

Thomas

----
Visit us at

---

From: "LEPROVOST YANN" <[email-masked]>
Date: Wed, 6 Feb 2008 16:34:15 +0100

Thomas, and all

I was actually thinking about the scenario of layered mutlicast over DVB-H/SH when I had the idea of using the frame rate...

I think there is a possible issue for mobile broadcast scenarios (such as DVB-H/SH) where we would like to implement graceful degradation with the coverage. The scheme is based on SVC layers coupled with unequal error protection on each layers, that rely on RTP session multiplexing for transport.

A simple scheme is to use multiple SVC dependency representations, all defined in the SDP. Let's take three dependency representation, each one transported over a separate RTP session, over a dedicated multicast address. S2 depends on S1 that depends on S0. At the link and/or physical layer of DVB-H/SH, unequal error protection is applied such that S0 is strongly protected, S1 with less protection and S2 with low protection. The objective for a client is to retrieve S0/S1/S2 in good conditions, S0/S1 in mid conditions, and only S0 in bad conditions.

Using the reordering process currently defined in draft 7, this objective seems not to be feasible. The packet loss effect is shown in current figure 2 of draft 7, AUs with TS4, 2, 1 and 3 are lost... despite the fact that AUs with TS2, 1 and 3 are decodable up to S1.

In fact, any packet loss in S2 will leads to the loss of the entire AU, no available lower dependency representations will be outputed despite the fact that they are correctly received and may be fully decodable by an SVC decoder. It contradicts the property of graceful degradation...

Hence, I still think that the receiver should not use the highest dependent session, but the session providing the highest number of AUs (that I associate to the dependency representation of highest frame rate) without packet loss for this scenario... 

Regards 

Yann

-----Message d'origine-----
De : Thomas Schierl [mailto:[email-masked]] 
Envoyé : mercredi 6 février 2008 14:20
À : [email-masked]
Cc : [email-masked]; LEPROVOST YANN; [email-masked]
Objet : RE: [AVT] draft-ietf-avt-rtp-svc-07.txt: classical RTP DecodingOrder Recovery Mode

Ye-Kui,

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.

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. And, that of course should make the RTP re-ordering process in case of packet loss much easier to implement, since timestamp order is equal to decoding order. Anyway, currently we are talking about native RTP mechanisms. Since there is no interleaving in the sessions, these mechanisms should perfectly work without the need of any additional indicators for decoding order.

Thomas

> In my understanding, the method finally specified should be generic 
> and be able to handle any situation, including non-constant frame 
> rate, packet losses, etc.
>
> >ext LEPROVOST YANN
> >Timestamps included in RTP packet header are derived from the frame 
> >sampling times at the emitter, that is, the sequence of TS values (in 
> >display order) reproduces the sampling instants of the video sensor.
> >As I have not heard of any system using non constant sampling period 
> >(at least in mobile TV applications), I assume that the sequence of 
> >TS in display order should reproduce a constant frame rate.
> >
> >Regards
> >
> >Yann
> >6 février 2008 00:59 À : LEPROVOST YANN Cc : [email-masked] Objet : Re: 
> >[AVT] draft-ietf-avt-rtp-svc-07.txt: classical RTP Decoding Order 
> >Recovery Mode
> >
> >A cursory viewing of your powerpoint implies that at least one method 
> >you have requires known/constant framerates.
> >
> >--
> >Randell Jesup
> >"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."

----
Visit us at

GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February 2008 / Broadcast Mobile Convergence Forum / Booth 2B82 http://www.mobileworldcongress.com/homepage.htm

OFC 2008 / San Diego, California, USA / 26 - 28 February 2008 / Booth 411/415 http://www.ofcnfoec.org
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: "Thomas Schierl" <[email-masked]>
Date: Wed, 6 Feb 2008 16:45:58 +0100

Ok, I see your point. The case you described still works with 8.1.1. But, we
may need to change the text in 8.1.1, e.g. to

"o The access units SHALL be passed in order of decoding order
     appearance of timestamps in the highest AVAILABLE Enhancement RTP
session to
     the decoder."

Thomas

> From: LEPROVOST YANN [mailto:[email-masked]]
> Sent: Wednesday, February 06, 2008 4:34 PM
> To: Thomas Schierl; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [AVT] draft-ietf-avt-rtp-svc-07.txt: classical RTP
> I was actually thinking about the scenario of layered mutlicast over
> DVB-H/SH when I had the idea of using the frame rate...
>
> I think there is a possible issue for mobile broadcast scenarios (such
> as DVB-H/SH) where we would like to implement graceful degradation with
> the coverage. The scheme is based on SVC layers coupled with unequal
> error protection on each layers, that rely on RTP session multiplexing
> for transport.
>
> A simple scheme is to use multiple SVC dependency representations, all
> defined in the SDP. Let's take three dependency representation, each
> one transported over a separate RTP session, over a dedicated multicast
> address. S2 depends on S1 that depends on S0. At the link and/or
> physical layer of DVB-H/SH, unequal error protection is applied such
> that S0 is strongly protected, S1 with less protection and S2 with low
> protection. The objective for a client is to retrieve S0/S1/S2 in good
> conditions, S0/S1 in mid conditions, and only S0 in bad conditions.
>
> Using the reordering process currently defined in draft 7, this
> objective seems not to be feasible. The packet loss effect is shown in
> current figure 2 of draft 7, AUs with TS4, 2, 1 and 3 are lost...
> despite the fact that AUs with TS2, 1 and 3 are decodable up to S1.
>
> In fact, any packet loss in S2 will leads to the loss of the entire AU,
> no available lower dependency representations will be outputed despite
> the fact that they are correctly received and may be fully decodable by
> an SVC decoder. It contradicts the property of graceful degradation...
>
> Hence, I still think that the receiver should not use the highest
> dependent session, but the session providing the highest number of AUs
> (that I associate to the dependency representation of highest frame
> rate) without packet loss for this scenario...
>
> Regards
>
> Yann
>
> 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.
>
> 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. And, that of course should
> make the RTP re-ordering process in case of packet loss much easier to
> implement, since timestamp order is equal to decoding order. Anyway,
> currently we are talking about native RTP mechanisms. Since there is no
> interleaving in the sessions, these mechanisms should perfectly work
> without the need of any additional indicators for decoding order.
>
> Thomas
>
> method
> GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February 2008 /
> Broadcast Mobile Convergence Forum / Booth 2B82

----
Visit us at

---

From: Randell Jesup <[email-masked]>
Date: Wed, 06 Feb 2008 11:48:50 -0500

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

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

>> have
>> 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
>> uses, and scalability might be very useful there when the receivers
>> (power or bandwidth) vary, or if it's a conference.
>

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.

---

From: <[email-masked]>
Date: Thu, 7 Feb 2008 03:43:41 +0200

I am still concurring with Randell on the following point:
- The solution for decoding order recovery process (in the final RFC)
must be able to deal with both constant variable frame rate use cases. 

I am also concurring with Yann on the following point: 
- The solution for decoding order recovery process (in the final RFC)
must be able to GRACEFULLY deal with packet losses. To the extreme, the
process must be able to pass all the received NAL units to the video
decoder in decoding order. Discarding NAL units by the payload format
(depacketization) process seems to have an architectural issue - NAL
unit discarding should be handled by the video decoder. 

Unfortunately, since before the previous IETF meeting, the biggest open
issue for this draft remains to be NAL unit decoder order recovery for
session multiplexing!  

Are people now ready to make judgment on this issue in terms of the
following?
- To have only one of the two options in subsections 8.1.1 ("the
classical mode") and 8.1.2 ("the CL-DON mode"), or both?
- If to have only one, which one?

If people are still not ready to think about the issue because of the
text clarity, please express which parts of the related text are still
not clear enough, e.g. as Randell commented in the bottom that "8.1.1 is
still more than a bit confusing, even with the example". 

To help people make their judgments, let me try to summarize the pros
and cons of the two modes. Many of these have already been discussed
earlier in the mailing list - but they still need to be considered for
the group to make a conscious decision. 

Cons of "the CL-DON mode" and pros of "the classical mode":

- The single NAL unit packetization mode cannot be used in "the CL-DON
mode", while all the three packetization modes can be used in "the
classical mode". This backward compatibility related issue is the major
constraint of "the CL-DON mode". However, this constraint is diluted by
the following facts. A) As discussed earlier, it is still possible to
encapsulate only one video NAL unit into one packet, together with a
small PACSI NAL unit that carries the CL-DON information. B) Currently
we are no aware of existing implementations of RFC 3984 that are capable
of doing multicast AND use only the single NAL unit packetization mode.

Pros of "the CL-DON mode" and cons of "the classical mode": 

- "The CL-DON mode" does not while "the classical mode" does rely on
timestamp (be it RTP timestamp or anything else) values to synchronize
NAL units carried in different RTP sessions. Using RTP timestamp for the
purpose requires that the RTP packets from the same access unit but
carried in different RTP sessions to have the same RTP timestamp value,
which seems have been basically concluded as not viable in the previous
AVT meeting. As for using other existing RTP synchronization mechanisms
for this purpose, there is an issue of the initial delay before the
synchronization among all the RTP sessions are done. 

- "The CL-DON mode" does not need to run separate NAL unit decoding
order recovery processes for the all the sessions before recovering the
decoding order for all the sessions. Only one process is needed for all
the sessions for "the CL-DON mode", and the process is the almost
exactly the same as the de-interleaving process in RFC 3984. In
contrast, "the classical mode" needs to run separate NAL unit decoding
order recovery processes for the all the sessions before recovering the
decoding order for all the sessions, and therefore, totally N+1
processes are needed for all the N sessions in "the classical mode",
wherein the N separate processes are exactly the same as in RFC 3984,
and the last process is totally new. 

- Generation and insertion of additional video NAL units to the original
bitstream is never needed by "the CL-DON mode" but may be needed by "the
classical mode". This generation and insertion of additional NAL units
may be required to be done by the RTP packetizer (not the video encoder)
when pre-encoded contents are used. Moreover, these additional NAL units
may make the original bitstream or a subset of it non-conforming to the
standard because of conflict in buffering (i.e. HRD - hypothetical
reference decoder) parameters.

- "The CL-DON mode" outputs all received video NAL units to the video
decoder, while "the classical mode" has to discard some received video
NAL units in some cases of packet losses. This in some cases will
degrade the decoded video quality because some useful video NAL units
are discarded. Furthermore, from an architecture point of view, handling
(including discarding) of video NAL units should be the video decoder's
task not the RTP payload depacketization process. 

- "The CL-DON mode" allows to carry non-VCL NAL units such as parameter
sets and SEI messages only when they are required (i.e. non-VCL NAL
units can be carried in the RTP session that carries the VCL NAL units
with which the non-VCL NAL units are associated with), while in "the
classical mode" all the non-VCL NAL units have to always be carried in
the base RTP session. Carrying of these additional data in the base RTP
session requires additional bandwidth for transmission of the base RTP
session, and the additional data may make the bistream subset carried in
the base RTP session non-conforming to the standard because of conflict
in buffering (i.e. HRD - hypothetical reference decoder) parameters.

Finally, here are what I think still needed to clarified in subsection
8.1.1 ("the classical mode") for people to better understand the
process. The text for subsection 8.1.2 (the CL-DON mode), which I should
be responsible for, is clear enough to me. However, please let me know
if I still need to improvement any parts therein. 

- What exactly is the "timestamp"? If not the RTP timestamp, what is the
exact process to derive that "timestamp"?

- What is the size of the de-session-multiplexing buffer that contains
the output packets from the RTP process as specified in subsection 8.1
before the NAL units are depacketized and sent to the video decoder?

- When does the decoding order recovery between RTP streams of different
RTP sessions start (e.g. after what number of packets in the
de-session-multiplexing buffer or how long an initial time after the
first packet has entered the de-session-multiplexing buffer)?

- When generation and insertion of additional video NAL units to the
original bitstream is needed, what is the exact process for generation
and insertion of the additional video NAL units? How to ensure the
received bitstream subsets to conform to the SVC coding standard? 

- Packet loss may requires to discard received NAL units. When should
that happen? What is the exact process? The exact process is needed
because the size of the de-session-multiplexing buffer and the time when
the decoding order recovery between RTP streams of different RTP
sessions start will be affected by the NAL units discarding process.

BR, YK 

>From: ext Randell Jesup [mailto:[email-masked]] 
>Sent: Wednesday, February 06, 2008 6:49 PM
>To: Thomas Schierl
>Cc: Wang Ye-Kui (Nokia-NRC/Tampere); [email-masked]; 
>[email-masked]
>RTPDecodingOrder Recovery Mode
>
>>> >a wireless broadcast/multicast channel as DVB-H. In that case 
>>> >somebody
>>> may
>>> >lower session to the same or a higher frame rate than contained in 
>>> >the
>>> lower
>>> >session.
>>>
>>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
>>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.
>
>>> >frames with decoding order different from presentation order. This 
>>> >is
>>> due to
>>> 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
>[email-masked]