Multi Pass Vs Single Pass!![MPEG-4 & MPEG-2]

[Tuning]

Do u need 2pass(or more) encoding if u have large bitrate(>1Mbps) and bits/pixel value around 0.30bits/pixel?.I think at this situation the single pass VBR encoding will produce similar quality,as average bits/pixel value is not going to change.Any comments?

:) - Tuning

[Die*wrek*show]

If you are talking about automatic cq_vbr as in tmpgenc, I don't think its very efficient. I tried it and it creates larger files with more artifacts. I had it set to 15 because I was trying for good 2 cd svcd rip. It created a file somewhere around 1.9 gigs and crap quality. Two passes is a must imo.

[coona]

The lower bitrate (and I´m not sure that 1Mbps is so high) the better allocation of this bitrate you need. So I preffer 2 or more pass encoding.

[Tuning]

This discussion was about using GK/VDM/Nandub/VD or any other MPEG-4 Encoding application capable of multipass encoding.Sorry it was not meant on 2-pass encoding in MPEG-2.Bye:)


:pTuning

[coona]

This discussion was about using GK/VDM/Nandub/VD or any other MPEG-4 Encoding application capable of multipass encoding.

I´m not so stupid :D He He. But I preffer 2passes encoding anyway using GK/VD. Modern CPUs are pretty fast so each pass take about 2 hours only. 2 or 4 hours don´t make big difference for me.

[Tuning]

What will be the quality?Any detereoration in video @ high motion sequences?

-Tuning

[coona]

I guess that 2nd pass brings better (question is how much better)picture (frame) with less artifacts. And in my opinion it is more visible in high motion scenes.

[Die*wrek*show]

My mistake, tuning I read wrong. Either way though, 2 pass is better regardless of whether your encoding mpeg2 or 4.

[DDogg]

I don't do mpeg4, but doesn't mpeg4 have a quality oriented quantizer based 1 pass like CCE OPV or TMPG CQ? It sounds like two completely different methods or being confused together in these replies. One is bitrate and sizing based while the other is constant quality based. As said, I do mpeg2 exclusively and don't know much about mpeg4 but I/we may be able to learn something about both from any replies.

[Soulhunter]

Think a 2Pass/nthPass method is for every encode useful, that doesn't reach the size of a Quality based (Quant2) encode...

Means...

If the final size of the encode is smaller than the Q2 one, not all quantz are "2" ! So there are "lower" ones, and the enc. must know where to place them... So even with bits/pixel value of 0.30, there are much "lower quantz than 2" that must be located and placed the right way...

But I could be wrong... ;)

Bye

[jonny]

bits/pixel & bitrate doesn't give you valuable infos about the final quality.
Every movie compress in a different way (get 2 movies with the same length and encode both @ same resolution/filters but @ 1passqb, the final sizes will be different).

(tip: search for compressibility!)

[Tommy Carrot]

Originally posted by Tuning
Do u need 2pass(or more) encoding if u have large bitrate(>1Mbps) and bits/pixel value around 0.30bits/pixel?.I think at this situation the single pass VBR encoding will produce similar quality,as average bits/pixel value is not going to change.Any comments?

:) - Tuning

The difference between 2-pass and quality based 1-pass is: with 2-pass, you can set the target size or bitrate, while with 1-pass, it's unpredictable. For the same filesize, the quality should be the same.

[DDogg]

bits/pixel & bitrate doesn't give you valuable infos about the final quality. Every movie compress in a different way... jonny, I'm glad you posted since I was considering sending you a PM about the subject. I know you have spent a tremendous amount of time predicting quality and final size for mpeg4.

In mpeg2, especially CCE we have a "Q" based method called RoBa that uses CCE's OPV method which is defined as:

MPEG-2 (ES, One-pass VBR)-
Outputs MPEG-2 video elementary stream in one pass variable
bitrate (One-pass VBR) mode. The bitrate of each GOP varies
but quantization scale is almost the same2.

Luckily the information file created in this quant based process (called a VAF file) can then be reused in a standard bitrate based pass to slightly tweak the final file size. This results in a primarily Q based encode but size corrected. We use a "no more that 10%" correction rule in order to keep the quality from being distorted by the sizing pass.

Where I am going with this is that via X% sampling and the following extrapolation of final file size (you certainly know ALL there is to know about this) one can accurately predict the size within a few percent and more importantly know the final quality *before* the encode is actually done. Also, I think it could then be argued that quant based encoding would always be equal or superior to a bitrated based multipass/N-Pass of the *same* file size.

Thus, with the exception of the time for the sampling passes, the highest speed and the highest quality can then be achieved via a one pass method.

So, I am wondering if a similar method exists for use with mpeg4 or if it has been explored. In effect I am curious if a parallel to the RoBa method used with mpeg2 exists for mpeg4, especially if one exists that allows a quant based encode to be slightly resized via a bitrate based second pass.

BTW, r6d2 has done some pioneering work in accurate size projection via sampling using "The Newton - Raphson Method" which I think is some type of advanced calculus (way above my head). I would think it might also be useful to the Mpeg4 community: http://www.angelfire.com/droid/r6d2/ A general overview of that method can be found here:http://www.sosmath.com/calculus/diff/der07/der07.html

[jonny]

@Tommy Carrot:
For the same filesize, the quality should be the same
Not necessary, you probably get the same average quant (but in 2pass the quants can go up and down... some scene may look better, others may look worse compared to 1passqb).

Hi DDogg :)

I know you have spent a tremendous amount of time predicting quality and final size for mpeg4
I'm writing an encoder mainly to get a better prediction ^^ (i hope to solve soon the problems you have seen in the develop forum so i can start testing the new method)

Also, I think it could then be argued that quant based encoding would always be equal or superior to a bitrated based multipass/N-Pass of the *same* file size.
I was discussing about this with a guy last week. I think that with a costant quantizer encode the results are more consistent (same quality perception over all the movie).
With 2pass lower quantizers are given where the eye need this and high quants where the quality degradation is not visible. But sadly this can't be perfect, some scenes may look good and others really wrong (for example old DivX versions usually fill the end of the movie with lower quants).
There isn't a objective answer to this.
I usually target for 80% of the first XviD pass, this gives me an average quant = ~2.5 (in this case will be difficult to spot differences between 2-pass & 1-passqb@2.5, but the 2-pass at least hit the target size).
I haven't tested cases with lower quality (for example 66%comptest&2pass vs qb@quant=3 or 50% vs qb@quant=4), you could try to check this to see what you like more (the guy i've mentioned above is happy with qb, but IIRC he don't go higher than quant=3 ... he uses GKnot + some calculations to choose the resolution and fit the movie in the target size).

Thus, with the exception of the time for the sampling passes, the highest speed and the highest quality can then be achieved via a one pass method.
If one day i'll start writing a codec (some dreaming here ^^), be sure i'll go to implement only quality based mode (hitting the target size with some kind of size prediction). Results can be better IMHO filtering high motion scenes instead of compressing with a different quant (there is an interesting app over the XviD forum that generate an avisynth file based on motion- not yet checked it but seems interesting).

So, I am wondering if a similar method exists for use with mpeg4 or if it has been explored. In effect I am curious if a parallel to the RoBa method used with mpeg2 exists for mpeg4, especially if one exists that allows a quant based encode to be slightly resized via a bitrate based second pass.
I assume you want to resize in order to hit a target size (right?).
If you are going to do a second pass in any way, why don't use a 2-pass restricting min & max quant in XviD?
With a comp. test you can use this (it's an approximation but works):

average_quant = 2 / comptest_value

An example, suppose you get 55% as comptest value.
average_quant = 2 / 55% = 3.6
Now if you set maxq=4 & minq=3, you should hit target size without obtaining too much quality fluctuations.
Another thing, comptest_value = target_size / predicted_size_at_qb2 (you can calculate more things with this).

BTW, r6d2 has done some pioneering work in accurate size projection via sampling using "The Newton - Raphson Method" which I think is some type of advanced calculus (way above my head). I would think it might also be useful to the Mpeg4 community: http://www.angelfire.com/droid/r6d2/ A general overview of that method can be found here:http://www.sosmath.com/calculus/diff/der07/der07.html

IIRC i've seen something like this long time ago (8-9 years? ^^), implemented in asm (to fast calculate roots).
Going to check all ^^

I hope it's all readable (my english is getting better every day... i hope :D )


PS: i had a discussion (some time ago) with a guy on DivX forum, IIRC he had tested that the DivX's multipass target it's to encode each frame with the same quant.

[Tuning]

Well I'm not a expert in MPEG-4 internal details,but can i ask this question:Is it possible to set the quant value to some maximum & minimum and integrate to an application?(may be VDM)


I have seen quantizer in Xvid tab,but i don't know what is it exactly :( .Can any one give a brief note.Thanks


:) - Tuning

[jonny]

Well I'm not a expert in MPEG-4 internal details,but can i ask this question:Is it possible to set the quant value to some maximum & minimum and integrate to an application?(may be VDM)
No, it's the codec that decide this (and if there is no option on the codec's setting window, there is no way to force any mix/max value)

I have seen quantizer in Xvid tab,but i don't know what is it exactly .Can any one give a brief note.Thanks
To simplify things: every frame get compressed with a different quant, lower quantizers give better quality, quant=2 is the lower limit.
You can also use quant=1 but in this case the file size will really grow (without giving a huge increment on the quality side)
Searching for this will surely give you more details.

[Mug Funky]

hmm. i simply don't have time for 2 pass these days (heh. must be my highly exciting go-getting life...).

i've recently found TMPGenc's CQ to be quite nice. set quality to 70, p frame spoilage to 20, and b-frame spoilage to 40 (high numbers, but worth it) and you'll get very acceptable SVCD at ~1140 kbps. (this was for a reasonably high-motion progressive video).

basically the spoilage settings translate to quantizer scalings (like in xvid). so a CQ of 70 will give constant quantizers of 6, but the spoilage settings mean you get 6 for I frames, 8 for P-frames and 10 for B-frames. the MPEG-2 quants are different from the MPEG-4 ones - a constant quant of 6 would be sub-standard in xvid, but is pretty damn nice in TMPG.

only drawback is the slightly unpredictable bitrate - the more action, the higher bitrate. but i got lucky this time, and got a consistent average of 1140k.

[DDogg]

Mug Funky, you might want to play around with the "best kept secret" of mpeg2 which is tylo's Conditional RoBa plugin for dvd2svcd/DVD and CCE. Beautiful one pass constant quality based encodings which automatically increment disk count to hold the user specified "Q", OR Pre-Predicted "Q" level for sizing based encodings where you specify the end size you want. It is particularly powerful when coupled with r6d2's "FACAR" autosizing script plugin for dvd2svcd.

It is really quite remarkable. Also, AFAIK, The conditional RoBa method tylo's plugin uses with CCE is the fastest method in existence for high quality mpeg2 encoding. http://home.no.net/tylo/ again, when coupled to r6d2's FACAR autosizing/autocropping script plugin it really starts to rock. http://forum.doom9.org/showthread.php?s=&threadid=61423

[chemmajik]

XVid CQ with a good high bit rate for captures, you can always come back & recompress... I hate wasting time on slow long compresses, always have always will data cd's are to cheap. Until theres a Virtual Dub for Mpeg2, I really just have stopped totally using mpeg2, especially with mpeg4 getting better results with smaller sizes. Now if I was doing HDVCR mpeg2 might be used more...

[lamapoo]

Correct me if I'm wrong. But what I've understood from this thread is that If I'm encoding at high bitrates (let's say 3Mb) I don't really need to two pass encoding.

[jonny]

Not exactly.
If you are near to saturation (so if with your bitrate you get maximum quality) you don't need 2-pass.
You can reach max quality with movie1 at bitrate1, while with movie2 you need bitrate2 (bitrate1 and bitrate2 are different).
So there is no high or low bitrate in general, only high and low compressibility.

[Neo Neko]

I had an interesting discussion with someone a while back who had a method of 2-pass constatn quality encoding that they were doing. They would first encode the video with 100% quality. Then they would find the percentage of differnece between the resulting file size and their desired file size. They then subtract that from the 100% and encode at the resulting quality percentage. When you think about it; it is a rather intriguing method. Apart from calculating file size differences you don't have to calculate BPP or much of the other things we may normally do. And you can easily understand how the quality of your final file will look simply by the quality percentage you are encoding at. I don't do it myself. But it makes sense and is intriguing none the less.

[jonny]

Yep, but probably there is a large filesize error doing this.

DDogg had point me on the Roba Q finder method, something like this can be implemented on mpeg4 (i've started a little app ^^).

Think at something like this:

Running multiple size prediction encodes until you find the quantizer nearest to your target size and, after this, running the qb encode with this quant.

In a general case you'll go to use 2% and you'll need 4-8 encodes, so the time for the quantizer prediction will be really little (10-20min) and the final size error quite low (probably 10% in the worst case and 3% in a normal case).

I find this interesting too, since even if you don't go for the final qb encode, you know exactly where the 2-pass encode will go in the quantizer scale (an additional compressibility info).

[MfA]

Constant quantizer is not constant quality.

[Neo Neko]

Originally posted by jonny
Yep, but probably there is a large filesize error doing this.


Well I have not tested it to any extent. But it appears that as you scale the quality the file size scales right along as well. Which means that you should be able to fairly accuratly hit the desired file size.

[jonny]

Not :(
Take a look at this (some XviD's tests from DDogg):

Quality Size of Sample in KB:
(quality from 65 to 98)

65 884
66 904
67 918
68 932
69 948
70 972
71 992
72 1016
73 1036
74 1052
75 1074
76 1104
77 1148
78 1172
79 1208
80 1246
81 1286
82 1328
83 1386
84 1436
85 1504
86 1570
87 1636
88 1722
89 1786
90 1892
91 2050
92 2178
93 2304
94 2574
95 2804
96 3116
97 3596
98 4258

Putting this to a graph you'll see the curve.
I've done some tests with DivX and the curve change if you change clip/codec's config (but those curves are all similar).

[r6d2]

Hi, guys.

I'm new to DivX. I've been experimenting with it to get archive-level quality encodes, on a "size does not matter" perspective.

I'm really, really surprised by the results obtained with MPEG-4 with bitrates as low 1000 kbps.

I've found that I can use MPEG-4 encodes to later create a SVCDs with reasonable quality indeed.

In this scenario Quality based encoding is my target. Your experience and comments have been enlightning. I hope some day to incorporate some of this knowledge into The Idiot's Guide to make it more general and not so CCE/DVD2SVCD oriented.

Believe it or not, I've been having a hard time cropping and resizing, in spite all the posts and guides I've read (I'm kind of AR freak ;)). I hope I can apply some of the FACAR concepts too.

Any input on the matter will be greatly appreciated.

[fccHandler]

@Neo Neko:

Are you referring to a suggestion I made a long time ago on DivX.com regarding a "linear relationship" between quantizer and file size? (I wish I could find the link to that discussion, but the DivX forums are trashed ATM.) Back then I think the latest version was 5.0.2, and it sort of worked with that codec. But it was never 100% perfect, and now it doesn't seem to work at all with later versions. I gave up on it not very long after our discussion.

As jonny's numbers demonstrate, XviD's quality / file size relationship describes a curve, which complicates the math a bit. Still it would be interesting if a good working formula could be derived from tests like that...

[r6d2]

Originally posted by fccHandler
As jonny's numbers demonstrate, XviD's quality / file size relationship describes a curve, which complicates the math a bit. Still it would be interesting if a good working formula could be derived from tests like that...
That curve is actually quite similar to the one you get when relating CCE Q.factor and bitrate.

You can see some research here (http://forum.doom9.org/showthread.php?s=&threadid=60191).

The curve can be modeled quite well by a n-degree polinomium, which you can find by having n+1 samples.

However, as it can be shown, iterating using the Newton (http://forum.doom9.org/showthread.php?s=&postid=361071#post361071) method is straightforward and lets you find a useful "root" in 2 or 3 tries.

[jonny]

@r6d2:

This could be interesting (you also find a little graph):

http://forum.doom9.org/showthread.php?s=&threadid=62662
(look at my 2 posts at the bottom)

@fccHandler:
I doubt about "linear relation" in DivX 5.0.2 (quite sure of this).
An approximation of the real case is something like this:

ave_quant = 2 / comp_test_value

or:

ave_quant = 2 / (your_target_size / size_at_quant=2)

As you can see, after you know the size of a quality based encode at quantizer=2, you can derive everithing (this graph (http://jonny.leffe.dnsalias.com/doom9/test.gif) give you an idea of the error).

PS: the last test i've done about this is with DivX 5.0.3, i can tell nothing about newer versions.

[r6d2]

Originally posted by jonny
[B]@r6d2:

This could be interesting (you also find a little graph):

Well, I think we've been working in the same stuff on paralell universes ;)

I don't know about you, guys, but it takes my computer about 7 hours for the first pass and 5 for the second with DivX 5.1 for a 3 hout movie.

I'd definetely go for a one pass method with prediction.

Regarding the error of prediction, I've done extensive research in MPEG-2 and my conclusions, which may also apply here, are these:

1. Sample size does not matter (increasing the sample exponentially does not reduce the error, i.e. file size does not converge). Ergo, sample size = 1% is enough (Yes, I know this is unbelievable ;)).

2. One pass quality based undersizes in 4 out of 5 cases the predicted size.

3. When oversizing, we do a second pass which reuses the first pass log data.

4. When undersizing, if the error is higher than a certain threshold, we do a second sizing pass too (as in 3).

[jonny]

Well, I think we've been working in the same stuff on paralell universes

:)


1. Sample size does not matter (increasing the sample exponentially does not reduce the error, i.e. file size does not converge). Ergo, sample size = 1% is enough (Yes, I know this is unbelievable ).

For mpeg4 this is different:
http://jonny.leffe.dnsalias.com/enc/sp/xvid.htm
http://jonny.leffe.dnsalias.com/enc/sp/divx.htm

If you take a look at 1%, 2%, 4% and 8%, in the majority of the cases increasing the sample increase accurancy (and 1% is too low in some cases).


2-3-4

Never done testing in this direction ^^, mainly because i rarely do quality based encodes (i mainly use size prediction for a raw indicator of quality).
Anyway, analisys in this direction are quite interesting!
But atm i'm still one step behind considering the entire figure :( (i'm working to reduce errors in a single size prediction).
I suspect that the size prediction with mpeg2 require less work compared to mpeg4, due to the differences between the 2 streams (to obtain good results, is there is no need to discard frames on mpeg2, right?).

[r6d2]

Originally posted by jonny
For mpeg4 this is different:

If you take a look at 1%, 2%, 4% and 8%, in the majority of the cases increasing the sample increase accurancy (and 1% is too low in some cases).
Interesting. Have you correlated the variables in an Excel dynamic table? You may find relations you woulnd't expect.

Though it's curious that, considered linearly, the error does not converge in the general case and in fact jumps back and forth quite strongly!
Never done testing in this direction ^^, mainly because i rarely do quality based encodes (i mainly use size prediction for a raw indicator of quality).
Well, me too. I used it to determine the number of CDs needed, and then use normal two pass. It was Tylo the one who advocated for one pass only. But if you're not a full-cd freak, 5% wasted CD space is not really that bad, considering that you at least got the quality you wanted.
(to obtain good results, is there is no need to discard frames on mpeg2, right?).
I don't know exactly what you mean, but no, I never discarded a frame in MPEG-2. I don't even know how to do it ;)

[jonny]

Interesting. Have you correlated the variables in an Excel dynamic table? You may find relations you woulnd't expect.

I don't have excel installed atm (never done things like this, if you have some time to check and posts your results/considerations, you are welcome :) ).


Though it's curious that, considered linearly, the error does not converge in the general case and in fact jumps back and forth quite strongly!

I have a theory about this, imo the error jumps because there is too much difference between samples.

I'll try to explain it better:

If you take a look at 1%, 2% 4%, 8% the error generally decrease.
If you take a look at 5%, 10% the error generally decrease.

So what happen?
At 1%, i encode 14 frames every 1400.
At 2%, i encode 14 frames every 700, so i'm using the same frames of 1%, (and of course i'm adding new frames).

At 5%, i encode 14 frames every 280, here i'm totally changing the sample set (entering a different "set" of errors).

This rule seems to apply in most of my tests.


I don't know exactly what you mean, but no, I never discarded a frame in MPEG-2. I don't even know how to do it

I think this is not needed because of the GOP length of the mpeg2 (?), basically the keyframe interval is really little, 12-18 frames if i'm not wrong.
What kind of error do you obtain with mpeg2 size prediction?

In mpeg4 the interval can be 200-300 frames long, encoding for example 14 frames every 1400 introduce an artificial keyframe on each of this 14 frames encoded (because of the jump, the codec detect a scene change and usually put a keyframe).
Since keyframes are quite bigger compared to normal frames, those artificial keyframes needs to be discarded in the size prediction calculations (to obtain good results).
(using bframes complicate things a lot, and more frames needs to be discarded! i'm working on this specific thing atm).


(Sorry for writing too much, i hope you find those stuffs interesting like i do ^^)

[r6d2]

Originally posted by jonny
[B]I don't have excel installed atm (never done things like this, if you have some time to check and posts your results/considerations, you are welcome :) ).
Well, I cannot do your homework, but I can show you how I did mine :). I have a prediction/resizing guide on the works. It's due some time soon, when I find the time.

At 1%, i encode 14 frames every 1400.
At 2%, i encode 14 frames every 700, so i'm using the same frames of 1%, (and of course i'm adding new frames).

Well, Your samples are "systematic". That's good for this.


What kind of error do you obtain with mpeg2 size prediction?
Nearly a normal distribution centered on 98% an with a variance of about 5-8%.

In mpeg4 the interval can be 200-300 frames long, encoding for example 14 frames every 1400 introduce an artificial keyframe on each of this 14 frames encoded (because of the jump, the codec detect a scene change and usually put a keyframe).
In MPEG-2 we use GOP-sized slices. GOPs are typically 15 frames (One I-frame, or Key-frame in MPEG-4). The only difference I can tell is that your slices may contain more key-frames than on the natural encode.

Since keyframes are quite bigger compared to normal frames, those artificial keyframes needs to be discarded in the size prediction calculations (to obtain good results).
You mean you get a more accurate prediction?

Well, we don't discard them. Interesting this theory of yours.

For historic reasons we use GOP-sized samples. I'll try to do a test with really long GOP sizes and without scene detection to see if the results are more precise in MPEG-2.

(i hope you find those stuffs interesting like i do ^^)
You bet!

[fccHandler]

I finally found that old discussion I remembered on DivX.com:

http://forums.divx.com/viewtopic.php?topic=44413&forum=6

[jonny]

@fccHandler:
It was pointed out to me that (with the same source video) a quantizer of 4 produces a file half the size of quantizer 2, and quantizer 8 produces a file half the size of quantizer 4
I'm sorry, i've misunderstood you, we are telling exactly the same stuff! :)

@r6d2:
Well, I cannot do your homework, but I can show you how I did mine.
Hehe ^^, i've tryed.
You mean you get a more accurate prediction?
For sure! But this is only true for mpeg4, since in a normal mpeg4 encode you'll not get all those keyframes (you must discard those frames or the prediction will be *really* oversized).
Well, we don't discard them.
Yep this looks ok to me, since your mpeg2 slices are a perfect samples of what you obtain in the real mpeg2 encode.
I'm quite new on mpeg2, so what i say about this is only theorical, perhaps i've given you some new ideas, but i suppose the current mpeg2 method is ok.




I'll try to summaryze the current state of size prediction on mpeg4:

Before b-frames:
Originally the slice size was 13 and the first frame of each slice was discarded.

With the b-frames introduction (DivX 5.0):
The slice size is now 14 for 2 reasons:
1 - DivX pack 2 frames (P and B) in one, so the slice size must be divisible by 2.
2 - Two frames gets discarded on each slice. The first frame (is the usual artificial keyframe) and the last frame (this contain, sometimes, an oversized b-frame - this happen when the codec doesn't detect a scene change between 2 slices).
Not discarding the oversized b-frame lead in an 15%-20% error in all cases.

With XviD things are more complicated (there is a special method), b-frames allocation can't be predicted and oversized frames can be found everywhere (of course always between 2 slices).
Actually 6 frames get discarded! 3 frames at the start and 3 frames at the end of the slices (i've compared this method with a couple of others discarding methods, it is the one giving the lower error in the majority of the tests).
I'm not happy about this solution, there are still some particular cases where the error is high (7%-8%) even analysing 10% of the movie.
This is where i'm working atm.

Some interesting notes:
Usually using a lower slice size (for example 4) gives lower errors, even if more frames gets discarded (this is valid with DivX).
So why 14 is used?
This have to do with mpeg2 and GOP size ^^.
The source for the mpeg4 encode is usually mpeg2. Encoding 1% of the movie with slice_size=4 takes more time than encoding 1% of the movie with slice_size=14 (first frames of the GOP needs to be decoded when the slice start inside a GOP).
Steady have done testing in order to find the lower errors in function of the time required for the encode, slice_size=13 was the result! (and he was really nice to make me understand this tricky stuff! *thanks*)


What a long letter... i hope is all comprehensible :)

[r6d2]

Originally posted by fccHandler
[B]I finally found that old discussion I remembered on DivX.com:
I read the whole thread, very interesting. However, as with most religious topics, the answer is completely open.

Anyway, the Quant concept is in a much smaller scale than Q.Factor. I encoded clips with Quant 2,3, 4, 6, and 8 and starting at 6 fddshow already shows 2 digits quantizers. Q.factor ranges 1~40 with quantizers below 6 or 7.

Thus unless fractional Quants make sense in DivX, I see little application of the second sizing pass of RoBa.

Besides, I think that quality based encoding is only for "I don't care the output size" kind of guys, which is reasonable IMHO because on a DVD-R you can put several movies, you're not longer constrained to 800-MB media as in the old days of SVCDs.

[MfA]

Maybe if there actually was a codec with a constant quality mode it would be more usefull too ;)

[r6d2]

Originally posted by MfA
Maybe if there actually was a codec with a constant quality mode it would be more usefull too ;)
Well, most of them have one, but defined as "quantization". "Quality" itself is in the eye of the beholder.

[jonny]

1. Sample size does not matter (increasing the sample exponentially does not reduce the error, i.e. file size does not converge). Ergo, sample size = 1% is enough (Yes, I know this is unbelievable).


On my tests (with CCE), increasing sample size actually increase accurancy:
http://jonny.leffe.dnsalias.com/doom9/mpv/std.htm
The test is done with 10 clips (the clips are taken randomly inside 2 movies, all the clips are 5000 frames long, so the errors are higher, compared to a normal case with a full movie)
Jumping at the bottom of the page you'll find the average errors.

I've done some tests checking "Restrict auto I frame insertion":
http://jonny.leffe.dnsalias.com/doom9/mpv/std_vs_gops.htm
"std" is with "Restrict auto I frame insertion" unchecked
"gops" is with "Restrict auto I frame insertion" checked
"gops" seems to be *slightly* better

I've done some additional testing checking "close all GOPs", but the results are worse.

I'm using a GOP size of 12 (M=3, N/M=4) and a slice size=12



2. One pass quality based undersizes in 4 out of 5 cases the predicted size.


I see a similar thing on my tests.
I *think* this could be an explanation:
With M=3, N/M=4 the GOP looks like: IBBPBBPBBPBB

IBBPBBPBBPBBIBBPBBPBBPBBIBBPBBPBBPBB

BB is slightly oversized, compared to a normal encode (because of the jumps done with the SelectRangeEvery, during the prediction)


I'm still a noob on CCE and i've never used other tools (apart the one i'm working on), so i can't compare the results, but perhaps something may be optimized on your current method (what you say in 1. make me think there is something wrong)

[r6d2]

Originally posted by jonny
but perhaps something may be optimized on your current method (what you say in 1. make me think there is something wrong)
Gee, I had forgotten this interesting thread ;)

You know, jonny, I cannot count the hours I've spent trying to increase prediction accuracy. Your tests are not the same as I did, but I'll have a look at what I did and post some results.

[jonny]

Returning on the mpeg4 side.

I've found this interesting XviD thread:
http://forum.doom9.org/showthread.php?s=&threadid=69457

from sysKin:

The quant distribution from 2-pass is definitely not better than constant quant - it's just more random and imprecise. I doubt you get a better picture by artificially introducing quantizer fluctuations...


... don't overestimate 2-pass encoding. It doesn't know what bitrate scenes need. It just tries to achive constant quant AND desired bitrate, which is simply more difficulat than constant quant alone.

So long life to qb encoding and size prediction! :D