Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500)

From: Zaheduzzaman Sarker <[email-masked]>
Date: Sun, 3 Nov 2013 16:23:48 +0000

Hi Xiaoging,

Clarification question.

>>a) delayed response to a rate change request (e.g., > 0.5s)

Where is this delay coming from? Fixed delay or delay based of some assumption lack of resource to process the request? Are you thinking of particular device, implementation?

BR

Zahed

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiaoqing Zhu (xiaoqzhu)
Sent: den 28 oktober 2013 13:15
To: Mo Zanaty (mzanaty)
Cc: rmcat WG; Colin Perkins; Michael Welzl; Varun Singh
Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500)

Agree with Colin and Mo.

For a statistical video traffic model, I would propose to break down the 2nd point (encoder rate control) in Mo's list further, to three sub-components:

a) delayed response to a rate change request (e.g., > 0.5s)
b) deviations from the requested rate (maybe as randomly fluctuating around the target?)
c) the different frame types or coding modes inside the encoder will yield some encoded
frames much larger than others. This will lead to burstiness on time scale of frame intervals
(typically 33ms), and later smoothed out by the pacing/shaper.

Also, if we go for the approach of using uncompressed test video sequence for testing the combination of video codec and congestion control, we should also recommend a reference codec and default configurations. So that focus of the evaluations remains on the congestion control module.  What do folks think of x264 (http://www.videolan.org/developers/x264.html)?

Best,
Xiaoqing

On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:

I agree with Colin. We should be focused on live encoding where the
encoder rate control is highly granular (often fully smooth) and coupled
to the network congestion control, not pre-encoded streaming of a small
set of fixed bitrates like DASH/HLS.

A more formal approach to the problem would be to decompose the factors
contributing to the final rate placed onto the network.
1. Video content / source statistics, using a large set of representative
sequences. An estimate of the entropy per frame could simply be the
encoded frame size using constant quantization, i.e. no encoder rate
control.
2. Video encoder rate control behavior, which modulates the source
statistics to fit into network constraints over rather large time
intervals (>0.5s).
3. Network transmission pacing / shaper, which smooths out bursts in
encoder output to fit into network constraints over fine time intervals
(<0.5s).

It should be possible to model all three in an abstract way to arrive at
some statistical model that can then be used for all tests without any
real video content or encoding (to avoid introducing noise in comparisons
if there was any variability in any of the factors).

Mo

On 10/28/13, 1:49 PM, Colin Perkins <[email-masked]<mailto:[email-masked]>> wrote:

On 27 Oct 2013, at 11:50, Michael Welzl <[email-masked]<mailto:[email-masked]>> wrote:

On 27. okt. 2013, at 12:33, Varun Singh <[email-masked]<mailto:[email-masked]>> wrote:

Now, next, what if we'd have a set of such sequences, and then stack
them over a codec that produces quite arbitrary bitrates, assuming that
the network can always follow it -

Do you mean preparing the same video sequence at multiple rates and the
congestion controller picking the appropriate media rate that fits its
estimate? ie rate switch between different media rates of the same
sequence?

I think that could be a very good idea!

I'd be more interested in a standard set of *uncompressed* video test
sequences, that we can use to test the combination of video codec and
congestion control. If we're building something for interactive video
congestion control we should assume live encoding, with the codec
potentially having the flexibility to react to the network, and our
testbed ought to reflect that.

--
Colin Perkins
http://csperkins.org/

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Sun, 3 Nov 2013 21:32:58 +0000

Hi Zahed,

We proposed such a delay term based on our understanding of the behavior of live encoder
rate control: it takes time for the encoder output rate to converge on the newly specified rate.
As such, it also means that the encoder cannot conform to arbitrarily frequent rate change
requests. Unlike CBR traffic, there is an inherent sluggishness in live encoder response.

So, strictly speaking, maybe we should call that term "sluggishness in response", or "convergence
time of encoder rate control”?

The aforementioned value (~0.5s) is based on our observations of encoder output traces
from one commercial video conferencing system. Other encoders may act differently and we
have yet to test them more extensively to confirm our conjecture. However, our guess is that
the order of magnitude of that value (say between 0.1s and 2s) will stay the same.

And, to clarify your question, we are not making any specific assumptions on why the encoder
is slow in response.  Rate control of live video encoding is an active research topic all by its
own, as the encoder needs to figure out what quantization parameters to choose for an incoming,
unknown frame, so as to meet the specified target rate.  Different encoders may achieve
different tradeoff in terms of responsiveness, accuracy, and computational complexity
(one-pass vs. two-pass, etc.).  For the purpose of RMCAT work, we are probably better off by
treating that as a black box.

Best,
Xiaoqing

On Nov 3, 2013, at 10:23 AM, Zaheduzzaman Sarker <[email-masked]<mailto:[email-masked]>> wrote:

Hi Xiaoging,

Clarification question.

BR

Zahed

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Xiaoqing Zhu (xiaoqzhu)
Sent: den 28 oktober 2013 13:15
To: Mo Zanaty (mzanaty)
Cc: rmcat WG; Colin Perkins; Michael Welzl; Varun Singh
Subject: Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500)

Agree with Colin and Mo.

Best,
Xiaoqing

Mo

--
Colin Perkins
http://csperkins.org/

---

From: Randell Jesup <[email-masked]>
Date: Sun, 03 Nov 2013 21:50:41 -0800

> statistics to fit into network constraints over rather large time

0.5 seconds to respond to rate-control changes?  Where?  Please fix that 
system! ;-)

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Sun, 03 Nov 2013 22:19:06 -0800

> the order of magnitude of that value (say between 0.1s and 2s) will 

Honestly, I'd love to know what systems have such long rate control 
delays.  The ones I've worked on have typically 1 or 2 frame times of 
delay -  I haven't measured the VP8 implementation in Mozilla, but I'd 
be shocked if it was much more than that (in fact, I've simply assumed 
that it's fast, and that if it wasn't things would be horribly broken).  
If your rate controller takes 1/2 *second* to hit a new requested rate - 
it's simply broken for realtime work, and likely the systems using it 
are usually used either well below congestion levels, or on dedicated 
links (which might be true for high-buck teleconference systems).

PLEASE do not optimize for rate controllers that take multiple hundreds 
of ms to respond.

(I'll verify with some codec people, just for sanity, before the session).

> treating that as a black box.

Two-pass, in realtime work?   Seems unlikely...  Maybe I just haven't 
played with enough high-bucks equipment on dedicated lines.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Sun, 03 Nov 2013 22:21:52 -0800

On 10/29/2013 11:29 AM, Dave Taht wrote:
> I would be very happy if also along the way, while exploring e2e cc 
> techniques for webrtc, that folk also tried the various aqm and packet 
> scheduling techniques being developed and deployed, other than drop 
> tail, notably wred, fq_codel, sqf & pie. That's a two way street as 
> I'd also very much like the aqm developers paying attention here 
> also... (I did some early work with webrtc + fq_codel earlier this 
> year but it was too buggy to get anything publishable.) 

In fact, one of the requirements is that the algorithm work when exposed 
to AQM (which may largely involve switching to a loss-reactive mode when 
it see no added delay at increased BW but increased loss).

AQM is out there (if not prevalent), and AQM one assumes will become 
more common.

-- 
Randell Jesup
[email-masked]

---

From: Dave Taht <[email-masked]>
Date: Sun, 3 Nov 2013 22:33:29 -0800

On Sun, Nov 3, 2013 at 10:21 PM, Randell Jesup <[email-masked]> wrote:
>> scheduling techniques being developed and deployed, other than drop tail,
>> notably wred, fq_codel, sqf & pie. That's a two way street as I'd also very
>> much like the aqm developers paying attention here also... (I did some early
>> work with webrtc + fq_codel earlier this year but it was too buggy to get
>> anything publishable.)
>
>
> In fact, one of the requirements is that the algorithm work when exposed to
> AQM (which may largely involve switching to a loss-reactive mode when it see
> no added delay at increased BW but increased loss).
>
> AQM is out there (if not prevalent), and AQM one assumes will become more
> common.

Based on the preliminary results from multiple cc papers I think the
success of webrtc and complex forms of videoconferencing is
inescapably conjoined with the need for and delivery of better packet
scheduling and aqm techniques in our bottleneck technologies
(DSL/cable/wifi/wireless)

-- 
Dave Täht

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Mon, 4 Nov 2013 06:40:18 +0000

Randell:

Just wanted to clarify: I do agree with you that the encoder will react/respond
almost immediately to a new rate change request.  However, I find myself hard
pressed to believe that:

a) It can do so on a very frequent basis, say, to conform to new rate changes once
per 0.1 second;

b) It can converge to the newly specified target rate within a very short window,
say, within two frames.

If, indeed, a) and b) are true, it would be wonderful if you could show us some
traces from those live encoders that hit a new target rate precisely within a couple
of frames, every so often. To be a bit more specific: if the target rate is changed
to 2.4Mbps for a 30 fps stream, then all ensuing encoded frames will come out
magically at a size of 10KB (= 2400000/8/30) within a couple of frames? Really?

I also wonder how that trick can be achieved, given that in live encoding, the
encoder can only do one-pass rate control (as you already noted, due to complexity
and latency constraints), and can at best guess at the scene complexity of an
incoming frame.

Curious to find out more ...

Thanks,
Xiaoqing

On Nov 4, 2013, at 12:19 AM, Randell Jesup <[email-masked]<mailto:[email-masked]>> wrote:

Honestly, I'd love to know what systems have such long rate control delays.  The ones I've worked on have typically 1 or 2 frame times of delay -  I haven't measured the VP8 implementation in Mozilla, but I'd be shocked if it was much more than that (in fact, I've simply assumed that it's fast, and that if it wasn't things would be horribly broken).  If your rate controller takes 1/2 *second* to hit a new requested rate - it's simply broken for realtime work, and likely the systems using it are usually used either well below congestion levels, or on dedicated links (which might be true for high-buck teleconference systems).

PLEASE do not optimize for rate controllers that take multiple hundreds of ms to respond.

Two-pass, in realtime work?   Seems unlikely...  Maybe I just haven't played with enough high-bucks equipment on dedicated lines.

--
Randell Jesup
[email-masked]<mailto:[email-masked]>

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Mon, 4 Nov 2013 17:54:46 +0000

We proposed such a delay term based on our understanding of the behavior of live encoder
rate control: it takes time for the encoder output rate to converge on the newly specified rate.
[Zaheduzzaman Sarker] Theoretically this can be done in next frame. Question is that do we need to take care of optimization features of codec implementation in congestion control design?
As such, it also means that the encoder cannot conform to arbitrarily frequent rate change
requests. Unlike CBR traffic, there is an inherent sluggishness in live encoder response.
[Zaheduzzaman Sarker] I don't know why this has to be true for CBR and not for VBR. The down switch on rate change should be fine with both CBR and VBR. Up switching is always dangerous and all my experience says you will perhaps not jump to the requested up switched bitrate directly but like to gradually go there. Hence you have enough time to reach to the higher bitrate. Anyway if the rate request is too frequent that's a sign of instable system to me.

So, strictly speaking, maybe we should call that term "sluggishness in response", or "convergence
time of encoder rate control"?
[Zaheduzzaman Sarker] I will regard that kind of sluggishness is a byproduct of optimization in coded and they will differ from implementation to implementation.

[Zaheduzzaman Sarker] will there be  any chance of making the survey available where we can look at the sluggishness in response in numerical values?

[Zaheduzzaman Sarker] so we  don't care about sluggishness in response , right?

Best,
Xiaoqing

Hi Xiaoging,

Clarification question.

BR

Zahed

Agree with Colin and Mo.

Best,
Xiaoqing

Mo

--
Colin Perkins
http://csperkins.org/

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Mon, 4 Nov 2013 18:54:17 +0000

Hi Zahed,

Please see my detailed replies inline.

To highlight my point, agree that we don't want to take care of codec implementation
issues in the design of a rmcat solution. However, we may want to capture the
imperfections in live video encoder rate control when evaluating the rmcat solution.

Now, looks like we are having very different assumptions about what a live
encoder can do — how fast and how perfectly it can conform to rate update
requests.  How about collecting some more data on this before making a call?
What popular codecs do people care about, for this purpose?

Cheers,
Xiaoqing

On Nov 4, 2013, at 11:54 AM, Zaheduzzaman Sarker <[email-masked]<mailto:[email-masked]>> wrote:

Yes, the encoder will react in the next frame. But it may not be able to generate a
frame with the perfectly fitting size (corresponding to the newly specified rate).
The encoder will need to guess at the new quantization parameter (QP) when encoding
an incoming frame with unknown scene complexity, and it takes time for the size
of the newly generated frames to converge around the new target.

We don’t need to take care of optimization features of codec implementation
in the design of congestion control scheme. But, I thought we were discussing
about how to evaluate a solution using a video traffic model. Then, the
behavior of the video traffic model had better capture the transient characteristics
of a live encoder output.

As such, it also means that the encoder cannot conform to arbitrarily frequent rate change
requests. Unlike CBR traffic, there is an inherent sluggishness in live encoder response.
[Zaheduzzaman Sarker] I don’t know why this has to be true for CBR and not for VBR. The down switch on rate change should be fine with both CBR and VBR. Up switching is always dangerous and all my experience says you will perhaps not jump to the requested up switched bitrate directly but like to gradually go there. Hence you have enough time to reach to the higher bitrate. Anyway if the rate request is too frequent that’s a sign of instable system to me.

By CBR I was referring to an ideal video source, which reacts promptly and
perfectly to rate update requests from the congestion control solution.

Looks like we åre agreeing on not having too frequent rate requests from
the congestion control solution. The question now is how often is considered
“too frequent”?  Obviously it cannot be more frequent than the frame intervals
(e.g., 33ms). Is an update once every 100ms (3 frames) acceptable?

Yes. That’s why we may want to capture a wide range of behaviors using a statistical
model, with a tunable parameter to represent different level of sluggishness in different
codec implementations.

Alas, we don’t have an extensive survey yet. Although, looking at the discussions here,
there is a real need for it. Or maybe the codec folks already have such info? What popular
codecs do we care about?

The data we have collected so far should only be considered as an example. Here is
link to one graph as an illustration (Michael will present it on Wednesday as well).
The graph shows a rate upshift from 1Mbps to 1.5Mbps at time t=5 sec.

https://www.dropbox.com/s/utg5jkgsvtkikvb/sample_trace_rate_upshift.png

[Zaheduzzaman Sarker] so we  don’t care about sluggishness in response , right?

IMHO: no for design, yes for evaluations.

Best,
Xiaoqing

Hi Xiaoging,

Clarification question.

BR

Zahed

Agree with Colin and Mo.

Best,
Xiaoqing

Mo

--
Colin Perkins
http://csperkins.org/

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Mon, 4 Nov 2013 22:01:52 -0800

Hi Xiaoqing,

Thanks for your detailed reply. Please see inline.

BR

Zahed

> imperfections in live video encoder rate control when evaluating the
I guess you are calling it "imperfections" from congestion control 
designers point of view :-). I think the "imperfections" are there for 
particular and valid reasons. I hope rmcat will able to list the 
possible imperfections if we choose to go in that path.
> requests.  How about collecting some more data on this before making a
that would be nice
> What popular codecs do people care about, for this purpose?
that is a very controversial question and I guess you asked that 
question to the WG.
>
> Cheers,
> Xiaoqing
>
>
> On Nov 4, 2013, at 11:54 AM, Zaheduzzaman Sarker
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> */[Zaheduzzaman Sarker]/**/Theoretically/**/this can be done in next
>> frame. Question is that do we need to take care of optimization
>> features of/**/codec implementation in congestion control design?/*
>
I guess then the “capturing transient characteristics of a live encoder 
output” need to be a part of the RMCAT requirements draft, right? The 
evaluation process is there to make sure requirements are fulfilled.
>> */[Zaheduzzaman Sarker]/**/I don’t know why this has to be true for
>> CBR and not for VBR. The down switch on rate change should be fine
>> with both CBR and VBR./**/Up switching is always/**/dangerous/**/and
>> all my experience says you will perhaps not jum/**/p/**/to
>> the/**/request/**/ed/**/up/**/switched/**/bitrate directly but like to
>> gradually go there. Hence you have/**/enough/**/time to reach to the
>> highe/**/r bitrate./**//**/Anyway if the rate request is too
>> frequent/**/that’s/**//**/a sign of instable system to me./**//*
>
I was referring to consecutive up switching and down switching of rate 
when talking about too frequent rate requests and instability not the 
rate request in the same direction. are we talking about same thing?

However, I dont think we need to settle down to a hard coded value. In 
some networks things might change slowly and in some the change is 
quick. To me a better congestion control algorithm need to address the 
network change in such a way that it does not show ping-pong pattern in 
rate change requests between up switching and down switching of bitrate.
>> *//*
>> */[Zaheduzzaman Sarker]/**/I will regard that kind of sluggishness is
>> a/**/byproduct/**/of optimization/**/in/**/coded and they
>> will/**/differ/**/from implementation to implementation./*
>
>> */[Zaheduzzaman
>> Sarker]/**/will/**/there/**/be/**/a/**/ny/**//**/chance of making
>> the/**/survey available/**/where/**/we can look/**/at/**/the
>> sluggishness in/**/response in numerical values?/*
>
>> */[Zaheduzzaman Sarker]/**/so we  don’t care about sluggishness in
>> response , right?/*
>
I am bit confused if the solution is not designed to take some 
properties of the system into account, why should one evaluate it 
against such properties? if you like to evaluate a solution against some 
properties, please put them in them in the requirements.
>
>> Best,
>> Xiaoqing
>> On Nov 3, 2013, at 10:23 AM, Zaheduzzaman Sarker
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Xiaoging,
>> Clarification question.
>> Where is this delay coming from? Fixed delay or delay based of some
>> assumption lack of resource to process the request? Are you thinking
>> of particular device, implementation?
>> BR
>>
>> Zahed
>> *From:* [email-masked]
>> <mailto:[email-masked]>[_mailto:[email-masked]] *On
>> Behalf Of***Xiaoqing Zhu (xiaoqzhu)
>> *Sent:* den 28 oktober 2013 13:15
>> *To:* Mo Zanaty (mzanaty)
>> *Cc:* rmcat WG; Colin Perkins; Michael Welzl; Varun Singh
>> *Subject:* Re: [rmcat] [rtcweb] Discussion on RMCAT traffic model in
>> Vancouver (03 Nov, 1300-1500)
>> Agree with Colin and Mo.
>> For a statistical video traffic model, I would propose to break down
>> the 2nd point (encoder rate control) in Mo's list further, to three
>> sub-components:
>> Also, if we go for the approach of using uncompressed test video
>> sequence for testing the combination of video codec and congestion
>> control, we should also recommend a reference codec and default
>> configurations. So that focus of the evaluations remains on the
>> congestion control module.  What do folks think of x264
>> (_http://www.videolan.org/developers/x264.html_)?
>> Best,
>> Xiaoqing
>> On Oct 28, 2013, at 1:39 PM, Mo Zanaty (mzanaty) <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>> On 10/28/13, 1:49 PM, Colin Perkins <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> On 27 Oct 2013, at 11:50, Michael Welzl <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> On 27. okt. 2013, at 12:33, Varun Singh <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> _http://csperkins.org/_

-- 

Zahed

==================================================
ANM ZAHEDUZZAMAN SARKER

Ericsson AB
Multimedia Technologies
Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43
[email-masked]
www.ericsson.com

==================================================

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Tue, 5 Nov 2013 16:38:36 +0000

Zahed, 

I mostly agree with what you’ve said, esp.  that: 
* the notion of “imperfections” is from congestion control point of video,
live video encoder rate control have good reasons to act that way, and
the design of a good rmcat solution should be mindful about that. 

So, ok, I should revise my last statement as “yes for design, and yes
for evaluations”.   

Just that I don’t yet see how we can state that crisply as a requirement. 
Can we say something more concrete than “works well with a real-world
video codec”, which seems to be too obvious anyway?  

Maybe, we could say “no undesirable ping-pong patterns” in rate request
change, and then specify what we mean by an undesirable ping-pong
pattern. Then we inevitably need to pick a value (or a range of value,
depending on which network we operate at) as undesirably rate change
frequency. 

Thanks,
Xiaoqing

On Nov 5, 2013, at 12:01 AM, Zaheduzzaman Sarker <[email-masked]> wrote:

> I guess you are calling it "imperfections" from congestion control designers point of view :-). I think the "imperfections" are there for particular and valid reasons. I hope rmcat will able to list the possible imperfections if we choose to go in that path.
>> 
> that is a very controversial question and I guess you asked that question to the WG.
>> 
>> Cheers,
>> Xiaoqing
>> 
>> 
> I guess then the “capturing transient characteristics of a live encoder output” need to be a part of the RMCAT requirements draft, right? The evaluation process is there to make sure requirements are fulfilled.
>> 
> I was referring to consecutive up switching and down switching of rate when talking about too frequent rate requests and instability not the rate request in the same direction. are we talking about same thing?
> 
> However, I dont think we need to settle down to a hard coded value. In some networks things might change slowly and in some the change is quick. To me a better congestion control algorithm need to address the network change in such a way that it does not show ping-pong pattern in rate change requests between up switching and down switching of bitrate.
>> 
>>> *//*
> I am bit confused if the solution is not designed to take some properties of the system into account, why should one evaluate it against such properties? if you like to evaluate a solution against some properties, please put them in them in the requirements.
>> 
>>> Best,
>>> Xiaoqing

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 6 Nov 2013 18:09:06 +0000

I should have used clearer wording. This is not about response time or
rate changes. It is the window over which the encoder will enforce the
average bit rate when there is no rate change. (VBV in MPEG terms.)
Typically a few frames, up to maybe tens of frames, assuming
semi-network-friendly real-time encoding. Like you said, it will steal
bits from some frames and give them back later, where later can be a few
or tens of frames. So the network will observe theft and generosity over
short timescales (if no shaper), which net to zero over longer timescales.
Adding a shaper gives the encoder more freedom to exploit content
statistics without agitating the network, but at the expense of potential
latency.

Mo

On 11/4/13, 12:50 AM, Randell Jesup <[email-masked]> wrote:

-- 
Randell Jesup
[email-masked]

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 6 Nov 2013 18:16:54 +0000

I think you are talking about different things. Most live encoders can accept changes in target rate almost immediately, which is Randell’s point. But they also have leaky bucket rate control algorithms that have time windows of several frames. When the target rate changes (assume instantly), that interacts with the leaky bucket in some way. A naive encoder which doesn’t expect getting hammered with frequent rate changes (like every frame) may do something dumb like reset all leaky bucket parameters upon target rate changes. Or it may alter fill rate but not bucket size or current occupancy level. I think that’s what Xiaoqing is trying to model. Maybe we don’t need to model such dynamics and make simpler assumptions. Or maybe use the MPEG VBV model and assume encoders conform to that.

Mo

On 11/4/13, 1:40 AM, Xiaoqing Zhu (xiaoqzhu) <[email-masked]<mailto:[email-masked]>> wrote:

Randell:

Thanks,
Xiaoqing