Log in

View Full Version : How many passes for CCE SP and when?


Pages : [1] 2

HornyBass
13th November 2004, 18:49
I've first followed the guide that is here on Doom9, and the guide from afterdawn.com, then came through another guide that is here : http://www.tutorial-cce.fr.st

It seems that I get better results with the last guide I've mentionned, but I'd like to understand better CCE SP 2.6x settings and when to tweak them.

Here are my questions :

- How many passes (VBR_Passes) to apply (I know that 3 is the minimum recommended, so it is to be set at 4 in DVD-RB)? How to determine the needed number of passes?

- How to determine the values to apply to VBR_Bias and Quality_Prec?

Thanks.

Khauron
13th November 2004, 20:00
I've used 6 passes. I know it is "too" much, but hey, that's why the nights are for ;-)
I've this idea that someone recommended 3 passes, because you really cannot see the difference in 3 vs 6 passes.
VBR_Bias and Quality_Prec, no idea, but doesn't DVD-RB have this extra-tool which tweaks the settings per movie?

TheSeeker
14th November 2004, 01:21
I would say 1+2 (so 3 in cce settings in RB) for light compressions and 1+3 so 4 in cce settings when more compression is needed. VBR bias of 25 and qual prec of 16 are pretty standard and work great. I would check out RB-Opt as it is an excellant add on for DVDRB. You open the rebuilder.ini file that is made with the prepare phase and with rb-opt you can apply custom matrices and tweak the avs scripts to include anything you want, and can adjust the bitrate by cell id. per vts. and much more.. Its really a must have.

HornyBass
14th November 2004, 01:35
Originally posted by TheSeeker
I would say 1+2 (so 3 in cce settings in RB) for light compressions and 1+3 so 4 in cce settings when more compression is needed. VBR bias of 25 and qual prec of 16 are pretty standard and work great. I would check out RB-Opt as it is an excellant add on for DVDRB. You open the rebuilder.ini file that is made with the prepare phase and with rb-opt you can apply custom matrices and tweak the avs scripts to include anything you want, and can adjust the bitrate by cell id. per vts. and much more.. Its really a must have.

As mentioned in the guide I've talked of in my first message, I have set VBR_Bias to 10 and Quality_Prec to 4, I seem to get better results than with the default values as details are getting more bitrate if I remember well what I've read on the guides.

I didn't had the patience yet to mess with RB-Opt, I use DVD Shrink when compression is at a max of 10% and DVD-RB+CCE SP when it is over 10%.

radar
18th November 2004, 09:50
hi hornybass
is thier a english version of that cce tutorial.looks like a good one.thanks

HornyBass
18th November 2004, 15:31
Originally posted by radar
hi hornybass
is thier a english version of that cce tutorial.looks like a good one.thanks

They only have it in french, you can look at the pics in it and try to find the settings they are talking of as tehy mention where they are in english most of the time, or look at the guide made by afterdawn.com and the one here on doom9.

radar
18th November 2004, 23:21
hey thanks hornybass
i know someone that speaks french,i get them to convert to english.then i will post it.

Boulder
19th November 2004, 13:09
I never use multipass VBR with DVD-RB. There is one specific reason not to do so.

The whole movie is not considered when encoding with multipass VBR, it is divided into small parts (cells?) which all have the same average bitrate regardless of the complexity of the video. Thus, a high-action part has the same average bitrate as a talking-heads one. If the whole movie was encoded in one piece, the bitrate would be divided better so that the high-action scenes would get much more bits than the low-motion ones. As the encoding is divided into small parts, this cannot happen.

With OPV, you don't have this problem as the Q parameter remains the same throughout the movie. The high-action scenes get more bits and low-motion ones get less.

Sir Didymus
19th November 2004, 14:44
Hi Boulder.

It seems to me your arguments are totally wrong. It is not true all the encoded cells have assigned the same average bitrate.

If you open with an editor the rebuilder.ecl file, in the AVS folder, you may easily note each cell is encoded with different parameters (settings) like the following:

vbr_brate_avg=xxxx
vbr_brate_min=yyyy
vbr_brate_max=zzzz

where these bitrates differ from cell to cell.

At the contrary, this is one of the plus of DVD-RB, respect to the one-step encoding applications: to analise the original bitrate allocation of the source contents, and to assign to each cell a bitrate proportional to the original allocation...

Cheers,
SD

TheSeeker
19th November 2004, 14:44
@Boulder

Actually Im pretty sure your wrong there. Jdobbs please chime in and correct me but i believe dvdrb looks at the original bitrates. (Which would most likely give more bits to the high action and less to the low action) and from there it makes its calculations and all that good stuff. So I personally believe your statement to be untrue, even though I cant prove it very definitivly. Jdobbs will ya help me out here?

Boulder
19th November 2004, 14:54
Now guys, you didn't see my point.

The point in a multipass VBR is that the bits are divided throughout the whole movie. They are not divided that way if the encode consists of several smaller parts.

This is just my opinion, and I knew that there would be differing arguments, but that was what I actually sought when writing that reply;)

TheSeeker
19th November 2004, 15:04
I believe this was the gist of your point:

The whole movie is not considered when encoding with multipass VBR, it is divided into small parts (cells?) which all have the same average bitrate regardless of the complexity of the video. Thus, a high-action part has the same average bitrate as a talking-heads one.

and this is what sir didymus and i are saying is wrong. The cells do not have the same avg bitrate. Each and every cell has a bitrate of its own and that bitrate is based on the original then made proportional so it can fit onto a dvd-r. and that original bitrate is based on high action or low action.

EDIT: MY point being that they DONT have the same average bitrate regardless of complexity of video. Anyone can see that.

Boulder
19th November 2004, 15:11
And what about the situation where you actually post-process the video (filter, resize, add overscan blocks)? The bitrate requirements don't stay the same..

TheSeeker
19th November 2004, 15:26
Now your just reaching to discredit multipass...

Boulder
19th November 2004, 15:30
Originally posted by TheSeeker
Now your just reaching to discredit multipass...

Care to explain a bit? ;)

Sir Didymus
19th November 2004, 15:34
Boulder,

This concept is not so complex: each cell of the movie is encoded in a totally different and separate encoding session, and a specific average bitrate is given to this cell, in order to match the original bitrate allocation.

This strategy, if you have no other a priori knoledge, is the optimal you can apply. If you have two different cells, one with an high bitrate allocated and the other with a low bitrate, you may apply all the filtering and resizing you want, but if you apply the same process to both, it's always better to give the first more bitrate than the second.

And there is no reason to give a relative weight to this allocation differently from the one defined for the original distribution...

TheSeeker
19th November 2004, 15:34
Well the exact requirements dont stay the same when applying filters but high action still needs more bits and low action needs less. I think thats what the first pass .vaf file is for. Also, I dont see what OPV mode does to correct for the application of filters.

Boulder
19th November 2004, 15:39
Originally posted by Sir Didymus

but if you apply the same process to both, it's always better to give the first more bitrate than the second.


I agree with you here.

TheSeeker: Probably the biggest difference between a multipass VBR and OPV is that the first one has to keep the average bitrate in mind all the time. OPV doesn't have that problem, it can spend 9500kbps for minutes and not worry about it. The user just has to worry about predicting the correct Q value - which for example tylo's excellent DVD2SVCD plugin does very well. But this is all pretty much OT here;)

Sir Didymus
19th November 2004, 15:51
Maybe I can add a very last comment on this subject: the only reason (which is a very valid reason) for using a single OPV step in your encodings is the time gain you obtain.

This is sometimes a very important argument, and the quality of OPV is in general very high.

If the time spent for the encoding is not a cost, then VBR encoding is the best choice: in one step the encoder defines the bitrate allocation and in the second step it actually gives this bitrate to the frames.

All further steps are "refinements". Never personally seen the need to do more than a single "refinement" step...

;)

SD

jorel
19th November 2004, 16:01
Originally posted by wmansir

CCE Options
CCE Basic (2.67+), CCE SP (2.66+), CCE SP (2.5)
Used to Select the version of CCE you are using.
One Pass VBR (w/Analysis) EXPERIMENTAL
DVD-RB performs a analysis of the video and then encodes with CCE One-Pass VBR mode. This requires half, or less, of the time for a normal CCE encode, but output size is not guaranteed and quality will be less than the standard Multi-pass method. See this thread (http://forum.doom9.org/showthread.php?s=&threadid=76663) for more details.
Advanced (Expert) Settings
These settings are for advanced users, and do not have to be changed from the default. More information can be found in the CCE FAQ (http://forum.doom9.org/showthread.php?s=&threadid=53770), Q. 7.[list=a]
VBR_Bias
This setting controls how CCE distributes the bitrate. To quote jdobbs:
"When you do your first pass the bit allocation per frame/gop is set based on a constant quality. The bias determines how much weight is given toward keeping that allocation. Setting it higher prevents wild swings in bit allocation between frames/gops. Setting it lower makes the encoder allocate more bits to high demand areas as needed and less to low demand. ...The higher you set this value, the closer you get to CBR rather than VBR."
VBR_passes
Sets the total number of passes the CCE encoder makes. NOTE: This setting is not equal to CCE's "passes" setting because CCE does not count the initial .vaf creation pass.
Quality_prec
Also known as Image quality Priority in CCE 2.5 and Quantizer characteristics in CCE 2.66 +. This setting ranges from 0-64, but is scaled for CCE 2.5 which uses a 0-100 scale.
This setting controls whether CCE gives priority to the fine details of the image, or evenly colored flat areas. A low setting will give priority to details, but could result in blockiness or color banding. A high setting will favor flat areas, but could result in edge artifacts. [/list=a]
6/8/2004 8:51AM

"CCE FAQ (Updated)"
Q7: What are the best settings?
And a few words about the number of passes for a multipass VBR encode in CCE-SP. The CCE-SP 2.50 manual says
quote:
--------------------------------------------------------------------------------
Image quality slightly improves each time encoding is repeated, but quality improvement reaches its limit at 3 ~ 4 times of encoding
--------------------------------------------------------------------------------

and you can trust it on that even for the later versions. Remember that in multipass VBR mode you have a fixed average bitrate and all that CCE-SP can do is try to find an optimal distribution of the available bits between easy and difficult to encode scenes. More passes will not make up more bitrate from air. You are free to use up to 9 passes, but, and this is strictly IMHO, anything more than 3 passes is just a waste of time at any given bitrate. 2 passes will be enough most of the time.

...and this is strictly IMHO, anything more than 3 passes is just a waste of time at any given bitrate. 2 passes will be enough most of the time
like is wroten is one opinion but who have patience to do 4 or 5 steps with CCE always get better results.
we have two types of tastes to encode:
fast for more or less quality or
slow with 5 passes for who want quality.
only who do 4/5 steps with CCE knows that the result is different and it's not one more opinion,that's a fact! only don't agree who never did it.
One Pass VBR (w/Analysis)is EXPERIMENTALand deserve extreme care and quality comparisons, not only velocity to encode.

TheSeeker
19th November 2004, 16:09
To Jorel

I HAVE done 4 passes before. I always used to do 1+4 passes, now I do 1+2 passes and I honestly dont see much of a difference at all. Except it only takes 2 or 2.5 hours now instead of 5 hours. You could starve on the difference in quality of video produced by the two methods.

jorel
19th November 2004, 17:00
Originally posted by TheSeeker
To Jorel

I HAVE done 4 passes before. I always used to do 1+4 passes, now I do 1+2 passes and I honestly dont see much of a difference at all. i have to agree with you.
you don't see much of a difference but....have differences and more passes are better. here you agree with that fact and with me ! ;)

Originally posted by TheSeeker
Except it only takes 2 or 2.5 hours now instead of 5 hours. You could starve on the difference in quality of video produced by the two methods. like HornyBass ask in his first post:Originally posted by HornyBass
" How many passes for CCE SP and when? "
when you have starve of quality(like me) use 4 or 5 passes, still the best option for that question! quality is the target, right? ;) you're a seeker of quality or not!?!? :p

ps: good signature. :)

Sir Didymus
19th November 2004, 17:29
Jorel,

Please consider, when you say more passes are better, you are assuming (since I can't believe you may measure this) that the encoding process is a stable (in the numerical meaning) process converging with continuity to a stable state which is "optimal".

This can not be demonstrated, so nobody can say in general, as it seems you say, that the multipass encoding performed by CCE is improving and under what conditions. Many people think and some one have evidence (like the writer) that after three passes (in total), the encoding process, for average bitrates around ~4500 is oscillating, meaning that it becomes a little bit better in one pass and becomes a little bit worse in the following.

I hope you agree the MPEG2 is a lossy compression standard, and bitrate and file size are constraining what an encoder can actually do. Most encoders (other than CCE) simply do not allow performing more than 2 passes in VBR. The reason for this seems very clear to me...

Respectfully speaking,
SD

TheSeeker
19th November 2004, 17:55
@Jorel

I agree with you that you may get a MINISCULE quality boost by doing 4 passes instead of 2... But for ME that little bit of a quality boost isnt worth the extra 3 hours. For YOU i guess is its so more power to ya.. do as many passes as you like.

Thanks for the compliments on the signature. Its from a series of fantasy books by Terry Goodkind called The Sword of Truth series. You should check them out if you are into fantasy books.

jorel
19th November 2004, 17:58
of course i agree cos he posted his opinion, not the fact or the result of comparisons...i can "swear(kiddin) that you never did 4 or 5 steps. sounds "strange" that you can't trust that i could measure this, is another opinion...then you're posting more opinions only. like i wrote, and one more time here, 4 or 5 steps are always better and jdobbs use max bitrate=5000cos don't think that need more (this is another point of view). go to tylo dv2Roba thread and read why i always choose more steps...sorry to say but you will need to use the search! :p and trust me, if you do, you will see the difference easily and not will "think" in the result! ;) do that only one time and proove to yourself. (we need to end to post facts against opinions,right?) :)

edited:
@ TheSeeker
sorry, we posted at the same time, my post was answering Sir Didymus
but now is for you my friend: choose a movie with hard actions using 4 passes with bitrate min=700 and max=8000 and compare with dvd-rb results(that is cool too of course, but...you will see)
best regards

jdobbs
20th November 2004, 02:31
jdobbs use max bitrate=5000cos don't think that need more I've never heard that before... much less have I said it.

jorel
20th November 2004, 07:40
Originally posted by jdobbs
I've never heard that before... much less have I said it.

oh,,sorry. i was using as reference the "imaginary dvd" that wmansir
use to explain how dvd-rb re-encode all cells inside DVD ReBuilder: Settings sticky....the average bitrate in the wmansir example will always get less than 5000 cos: "Here, we also achieve our 50% reduction overall. And each cell has a 50% individual reduction." as the max we can use in CCE is 9800.
and here you posted that was used "a much higher bitrate than was necessary" : http://forum.digital-digest.com/showthread.php?threadid=40640&perpage=15&highlight=jdobbs&pagenumber=3
and as 5000 is more than 50% of the max value used in CCE and as you wrote that: "DVDs out there that were made at a higher-than-needed bitrate to require dual layer only to make copying more difficult."
was only a single conclusion after read what you wrote and what is found in DVD ReBuilder: Settings. you don't wrote the value "5000" was only conclusive for me reading the informations!

chilledoutuk
21st November 2004, 02:16
Originally posted by Sir Didymus
At the contrary, this is one of the plus of DVD-RB, respect to the one-step encoding applications: to analise the original bitrate allocation of the source contents, and to assign to each cell a bitrate proportional to the original allocation...


I have a problem with this method as I believe the rate control in CCE is the best in the world for MPEG-2.

That rate control is optimized for the given average bitrate and to simply proportionally scale the original rate control from a higher average bitrate encode is simple wasting one of CCE's bigest strengths by limiting it the rate control of the original encoder (which may have not been CCE).

one of the most obvious cases where this approach is not optimal is when I re-encode long 3 hour films such as LOTR where the original average bitrate was around 5000kbps but the new re-encoded one was around 2800kbps it is obvious that the original rate control would be totally un suitable due to the massive difference in bitrate.

What really amazes me is that this method is totally unnecessary as there are already applications like DVD2DVD-R that encode and give CCE a free rain to do its magic and determine its own rate control for the video at hand.

Another clear disadvantage is the added time of CCE being restarted about 100 times and initialised to the encode duration.

I would also like to add that with the rate control being so limited in this approach the benefit of doing more that 2 passes is greatly reduced.

The bottom line is I trust CCE's rate control over any other encoders.

jdobbs
21st November 2004, 03:36
I have a problem with this method as I believe the rate control in CCE is the best in the world for MPEG-2. No one argues that point. In fact the way in which bitrate is distributed by CCE is one of the reasons you CAN break it up like this. This method has been tested and proven multiple times to be equal in quality to any other method using CCE.

If you have a problem with it... use something else. I believe you don't understand how it works -- or we wouldn't be having this discussion.

I could also point out multiple instances where the other CCE based software packages not only deliver worse quality -- but in fact don't work correctly at all. Try doing a mixed mode (telecined and interlaced) DVD with both and then come back to discuss it. Try the second COSMOS DVD, or better yet, STNG...

I have yet to have seen anyone lined up against a wall and told the HAVE to use DVD-RB. I personally use it because it works better than any other -- and I would even if it were written by someone else.

chilledoutuk
21st November 2004, 04:14
i am not trying to dis this application i just was a little confused as to why you use this method.

Im from PAL land so mixed mode dvds i have never had problems with but its good to know that rebuilder can handle them.

i dont suppose you could enlighten me as to how you determine the parameters for the encoding of each cell from the orginal stream as i find this of particular interrest.

also beacause of this method predetermining the rate control do you agree that extra passes are not needed as much?

jdobbs
22nd November 2004, 15:48
Reread your post and then tell me you really weren't trying to "dis" -- you also weren't showing any confusion. You made it clear that DVD-RB was doing "unnecessary" things and you made several other statements that, quite frankly, reflected your lack of knowledge as to how it works.

As for your enlightenment, I would recommend the "search" button -- as this has been discussed in depth on many occasions.

As for extra passes... I'd say the CCE recommended number still holds true. While the original DVD build would give you a good indication of how to distribute available bits between cells -- CCE still makes the decision within each cell.

chilledoutuk
22nd November 2004, 16:59
I was simply trying to asertain why it does what it does.

I dont quite frankly like your attitude i am new to dvd rebuilder but this does not mean i am new to cce i have been using cce since well before rebuilder even existed.

I am not trying to insult you or the application you have made regardless of what has been said but rather I am trying to understand your aproach to encoding dvds with cce.

one simple question though does your dynamicaly asign bitrates alglorithm look into the quant of each frame as well as the size in order to determine the cce parameters for each cell?

ps do you have any search hints as finding something this specific is quite difficult?

Sir Didymus
23rd November 2004, 14:46
@jorel
Sorry for the late answer, have been little bit busy in the last days...

Originally posted by jorel
i have to agree with you. you don't see much of a difference but... have differences and more passes are better. here you agree with that fact and with me !

jorel, here is you that are mixing up opinions (yours, and respectable, but opinions) saying that are facts...


when you have starve of quality (like me) use 4 or 5 passes, still the best option for that question! quality is the target, right?

Yes. Quality is the target, but unfortunately (or fortunately...), quality is subjective. Even the best definition of quality is normally given in terms of best practice... So all about this subject should better be reported as personal opinions, or personal experiences, not as facts.


of course i agree cos he posted his opinion, not the fact or the result of comparisons...i can "swear(kiddin) that you never did 4 or 5 steps. sounds "strange" that you can't trust that i could measure this, is another opinion...

When I wrote:
Originally posted by Sir Didymus
Please consider, when you say more passes are better, you are assuming (since I can't believe you may measure this) that the encoding process is a stable (in the numerical meaning) process converging with continuity to a stable state which is "optimal".

my intention was to say that you can not measure the convergence and the continuity of the encoding process respect to the number of passes. You can not perform this measure simply because the statement that the encoder is converging is not true. If you are looking at facts, I am happy about this: I followed your suggestion doing some tests on the matter.

I will report in a next post almost all of my findings as personal OPINIONS. But one of the very few facts that are easy to demonstrate is that the encoding process is not converging. This is because if you want to demonstrate the convergence, it is not sufficient to carry out 1000 encoding sessions: you have to write a mathematical demonstration. For demonstrating the encoding is not stable the matter is much easier: it is sufficient to find a single cell to show the fact. And this is exactely what I did...

Let me say also, that your opinions on the matter:

like i wrote, and one more time here, 4 or 5 steps are always better ...
...
and trust me, if you do, you will see the difference easily and not will "think" in the result! do that only one time and proove to yourself. (we need to end to post facts against opinions,right?)

Are totally different from mine. Again, respectfully speaking, if your backups are done adopting bitrates of 4000~4500 Kbit/s (as I normally do) my suggestion is never to perform more than 1+2 encoding steps: it's always time spent for nothing.

SD

Sir Didymus
23rd November 2004, 15:26
Just completed some tests...
It seems useful to me to share the results...

Important to underline that the following should be just retained as personal opinions. Even the relevance of what is reported is not general at all: since the quality is a subjective term it is clear that ANYONE is free (if he feels happy about) to use the settings and the number of passes in the encoding with CCE which is the most suitable and matching the own concept of visual quality.

Another weak point in what I am reporting is that in order to conclude anything it should be better to carry out much more tests on many different titles...

Also the mathematical tool adopted for making an objective evaluation (SSIM) is biased by doubts (more or less correct) regarding the metric adopted for the definition of the similarity index.

A reference (very suggested reading) to the method and to the excellent research work of Zhou Wang is the following:
http://www.cns.nyu.edu/~zwang/

The tool and the avisynth implementations seems to me satisfying (accepting some obvious limitations). Other tools for "objectivation" (PSNR or VqmCalc) have even stronger limitations.

Performed test was:

- taking the title Kill Bill Vol1 - PAL - R2
- run DVD-RB (rel. 067 in three click mode) and stopped at the end of the "prepare" step
- extracted one of the ecl control segments from the rebuilder.ecl file (Vob1 Cell3); it is the famous scene of the combat between Uma Thurman and Vivica Fox...

Extracted ecl segment is the following:


; Cinema Craft Encoder SP -- Encoder Control List
; Extracted for testing purposes from a file...
; Created by DVD Rebuilder

[item]
title=V01000200001003
aud_out=0
vaf_file=C:\KILLBILL_VOL1\RB_OUT\D2VAVS\V01000200001003.vaf
aud_file=C:\KILLBILL_VOL1\RB_OUT\D2VAVS\V01000200001003.mpa
file_focused=0
packet_size=2048
width=720
height=576
frame_rate_idx=3
cbr_brate=6000
vbr_brate_avg=4250
vbr_brate_min=0
vbr_brate_max=8552
seq_endcode=0
dvd=0
half_width=0
half_height=0
lum_level=0
aspect_ratio=3
gop_m=3
gop_nm=4
gop_hdr=12
seq_hdr=1
all_closed_gop=0
fix_gop_length=0
samples_per_sec=44100
stereo=2
brate_idx=7
crc=1
progressive=0
alternate_scan=1
intra_dc_prec=2
aud_mode=0
tc_ref_frm=0
drop_frame=0
fix_vbv_delay=0
letter_box=0
pulldown_detect=0
offset_line=0
create_new_vaf=1
credits_tweak=0
credits_start=0x00000
credits_brate=1000
h_filter=0
h_filter_idx=8
dither=0
dither_max=8
qmat_idx=0
quality_prec=16
timecode=0x0000000
video_type=4
vid_file0=C:\KILLBILL_VOL1\RB_OUT\D2VAVS\V01000200001003.m2v
vid_file1=C:\KILLBILL_VOL1\RB_OUT\D2VAVS\V01000200001003.m2v
vid_out=1
vaf_out=1
opv_q_factor=20
opv_brate_min=0
opv_brate_max=6841
vbr_bias=25
vbr_pass=1
use_filter=0
filter_val=6
non_linear=1
top_first=0
mpeg1=0
mpeg1_cps=1

[file]
name=C:\KILLBILL_VOL1\RB_OUT\D2VAVS\V01000200001003.avs
frame_first=0
frame_last=6797
encode_first=0
encode_last=6797


Note that the average bitrate is 4250, min 0 and max 8552.

This ecl file has been used for completing 9 encoding sessions with CCE, just changing the number of VBR passes [from 1 to 9].

Then used some Avisynth scripts (symilar to the following) for generating the 9 xls tables containing the SSIM values:


LoadPlugin("C:\Programmi\AviSynth 2.5\plugins\DGdecode.dll")
LoadPlugin("C:\Programmi\AviSynth 2.5\plugins\SSIM.dll")
original=MPEG2Source("E:\TEST_SSIM\D2VAVS\Source.d2v").ConvertToYV12()
encoded1=Mpeg2Source("E:\TEST_SSIM\D2VAVS\enc1.d2v").ConvertToYV12()
SSIM(original,encoded1,"SSIM_enc1.csv","AveSSIM1.txt",lumimask=true,scaled=false)
ConvertToYUY2()


First interesting result (for me it was not a surprise... maybe it is so for some one) is that the encoding sessions based on CCE
is not a stable process (in the numerical meaning, i.e. it is not converging) respect to the number of encoding passes, based on the SSIM metric.

In other words it is not true that making more steps the encoding improves (at least in terms of SSIM).

This is evidenced by the following indexes of the average SSIM, for the 9 encoding passes:

pass1: Average SSIM= 0.981479 Std. Dev. = 0,008241
pass2: Average SSIM= 0.981500 Std. Dev. = 0,008334
pass3: Average SSIM= 0.981509 Std. Dev. = 0,008280
pass4: Average SSIM= 0.981508 Std. Dev. = 0,008280
pass5: Average SSIM= 0.981508 Std. Dev. = 0,008278
pass6: Average SSIM= 0.981511 Std. Dev. = 0,008279
pass7: Average SSIM= 0.981508 Std. Dev. = 0,008279
pass8: Average SSIM= 0.981507 Std. Dev. = 0,008279
pass9: Average SSIM= 0.981508 Std. Dev. = 0,008280


Note that the encoding become worse, respect to the previous step, making 1+4 pass, and become repeatidly worse making 1+7 and 1+8 passes respect to 1+6.

Also note that the best encoding among all (with 1+6 passes) is differing by 11 x 10-6 (sigh!) respect to the one made with 1+2 passes.

In order to do a further subjective evaluation I adopted the following Avisynth script (kindly pointed out by junior73, in the Italian forum) to do a frame by frame comparison between encodings #1 and #9:


LoadPlugin("C:\Programmi\AviSynth 2.5\plugins\DGdecode.dll")
LoadPlugin("C:\Programmi\AviSynth 2.5\plugins\SSIM.dll")
original=MPEG2Source("E:\TEST_SSIM\D2VAVS\Source.d2v").ConvertToYV12()
encoded1=Mpeg2Source("E:\TEST_SSIM\D2VAVS\enc1.d2v").ConvertToYV12()
encoded9=Mpeg2Source("E:\TEST_SSIM\D2VAVS\enc9.d2v").ConvertToYV12()
resori=SSIM(original,original,"Sor.csv","AvSor.txt",lumimask=true,scaled=false)
res1=SSIM(original,encoded1,"S1.csv","AvS1.txt",lumimask=true,scaled=false)
res9=SSIM(original,encoded9,"S9.csv","AvS9.txt",lumimask=true,scaled=false)
A=StackHorizontal(resori,res1)
B=StackHorizontal(resori,res9)
Stackvertical(A,B)
ConvertToYUY2()


Results left me astonished: I spent more than one hour looking carefully at many frames, and I did not find any difference; not even one single difference. On many frames the SSIM value for the encoding #1 is actually better than for the #9. See for example the following three images (original, encoded with 1+1 passes, and encoded with 1+9 passes):

http://img122.exs.cx/img122/4001/1718orig.jpg

http://img122.exs.cx/img122/5810/1718enc1.jpg

http://img122.exs.cx/img122/7079/1718enc9.jpg

Just in order to cancel any residual doubts on the matter I found the frame, among the 6797 of the cell, having the maximum SSIM distance respect to the original. It is frame 2353. SSIM distance among them is 0,021483.

If you are able to see differences please tell me (or better, do not tell me; even if you find some differences you will not convince me to redo my backup making more than the 1+2 passes it took to complete the job some months ago...)...

http://img28.exs.cx/img28/9232/2353orig.jpg

http://img124.exs.cx/img124/425/2353enc1.jpg

http://img124.exs.cx/img124/7889/2353enc10.jpg

Every one may draw the conclusions more suitable for him/her. Concerning myself, I will continue to use my method with CCE that is the following:
when bitrate >= 4000Kbit/s I will use VBR 1+1 passes normally, without any further concern on the quality. For lower bitrates (even though I rerely go below ~4000), i.e. ~3500 or ~3000 or less the usage of some specific low bitrate or extremely low bitrate matrix would be much more effective and recommended than making an absurd number of encoding steps... Just in some cases where for some reasons I would find useful to squeeze CCE, for making my pc to loose some time and as an alternative to keep it switched off, I will use 1+2 passes... NEVER MORE...

This is my subjective view to the topic.

All the best,
SD

erdoke
23rd November 2004, 20:05
Sir Didymus,

This is a very thorough, I would say nearly scientific experiment.
But...
Do we need CCE to step in at all when we have an average bitrate above 4000? At an avg bitrate of 4500 I would rather choose a transcoder (for example CloneDVD2) and do the job in 10 minutes with very good quality. ;)
I guess CCE should be considered as a choice when we have an average movie (I mean lots of bright scenes and lots of action :D) and an average resulting bitrate below 4000 or even below 3500 kbps.
I would be more interested in your opinion on low bitrate encoding, different matrices vs. more passes.

Sir Didymus
23rd November 2004, 20:54
Hi erdoke! :)

It depends on the source, you know. Stripping out unwanted audio tracks, unreferenced material, FBIs, ... Really most of my recent backups are showing avg bitrates ~4000 or ~4500.

I personally think that the usage of a transcoder could be risky (meaning you risk to find yourself in the NEED of making two times the job) when the target size is below 90% of the original.

Regarding low bitrate encodings, as soon as I will find some backups where bitrate is ~3000 or ~3500 I will make some SSIM comparison: low bitrate matrices vs more passes... Also giving a try to Procoder: many claim that it is excellent at low bitrates... I promise, but it will be in the future...

jorel
24th November 2004, 00:20
Originally posted by Sir Didymus
@jorel
Sorry for the late answer, have been little bit busy in the last days...
SD
but this is cool,very cool Sir Didymus! :)
i only did one fast read and i need to re read (poor english).
differences? yes, really have but you don't want to know, or better, you don't want that i(we) show.best way to see differences is opening one new page for each picture:
http://img122.exs.cx/img122/4001/1718orig.jpg
http://img122.exs.cx/img122/5810/1718enc1.jpg
http://img122.exs.cx/img122/7079/1718enc9.jpg
http://img28.exs.cx/img28/9232/2353orig.jpg
http://img124.exs.cx/img124/425/2353enc1.jpg
http://img124.exs.cx/img124/7889/2353enc10.jpg
but .jpg pictures loose details in this case for deep comparisons and are "freezed" of course, little sequences from the source and from the encodes will show better details,right?
do you have or can cut little vobs to post? if you could do that will be amazing. :) if you can my preference is for --> very bright scenes cos i think that is exactly where the encoder really do the hard work....well, some people think the reverse, that in dark scenes show more details.
one thing is amazing for me and in this case seems irrelevant ....but let me ask: why and how the pictures have the same bright and colors intensity if encoding that parameters always change a little!?!?for this reason, Wilbert build the ColorMatrix (http://forum.doom9.org/showthread.php?s=&threadid=82217&highlight=colormatrix)filter....i saw that bright and color issues without any "mathematical tool adopted for making an objective evaluation" was only using my eyes...but this is one detail for another ocasion. we first will treat this point here and later about why and how encodes --> always loose details in colors and bright, in another thread ok? is one big surprise for me cos i never saw the exact bright and saturation without fade the colors resulting as the vobs source, like in the pictures here....this is the real surprise for me! ;) we can trust in "Zhou Wang" (accepting some obvious limitations),right?
i think that your tests are really cool and have my adimiration cos you search quality like i do but see some little vobs will be amazing for me and for all.if is possible, please do that, my eyes don't will see mistakes doing comparisons.
thanks for your atention and i'm waiting your samples...i need to re read all cos have very interesting details!
:)

Sir Didymus
24th November 2004, 10:29
Originally posted by jorel
best way to see differences is opening one new page for each picture...

I'll follow your suggestion in the future; it improves readability and makes shorter the post...


but .jpg pictures loose details in this case for deep comparisons and are "freezed" of course, little sequences from the source and from the encodes will show better details,right? do you have or can cut little vobs to post? if you could do that will be amazing.

That's not so difficult. I will post some links for downloading the whole dataset of the test, including the nine xls files with the SSIM values and the short m2v segment demuxed from the original vobs using VobEdit, together with the nine encoded m2v files. It should be easy, starting from the m2v, to build up some vob files, using the authoring tool you prefere...


one thing is amazing for me and in this case seems irrelevant ....but let me ask: why and how the pictures have the same bright and colors intensity if encoding that parameters always change a little!?!?for this reason, Wilbert build the ColorMatrix (http://forum.doom9.org/showthread.php?s=&threadid=82217&highlight=colormatrix)filter...

Dont'know the reason. I posted all the avs information (including all of the involved colorspace conversions) in order for everyone interested to repeat the test. Very interesting indeed your reference...

SD

Boulder
24th November 2004, 10:54
To get an even better comparison, do a test with OPV, Q value set so that the average bitrate is as close to the multipass avg bitrate as possible.

Tooting my own horn;)

Sir Didymus
24th November 2004, 11:26
@Boulder

Yeah, reading your posts I understood you are a "supporter" of OPV; I'll do this further little test on the same cell; it'll take not so much time, having all the files all ready. It seems to me (this one) it's really a good suggestion...

By the way, like very very much your signature... :cool:

pg55555
24th November 2004, 14:45
Sir Didymus
when bitrate >= 4000Kbit/s I will use VBR 1+1 passes normally, without any further concern on the quality. For lower bitrates (even though I rerely go below ~4000), i.e. ~3500 or ~3000 or less the usage of some specific low bitrate or extremely low bitrate matrix would be much more effective and recommended than making an absurd number of encoding steps...
It is realy a very interesting and helpfull analysis, and it will surelly prompt me to reduce my standard 1+4 passes to a faster 1+2 passes.

But, not offense intended, it is not a little biased? What I mean is, making the comparison with a cell with a VBR average of 4250 it is not a way to assure that there will be little gain with extra passes? If you have a decent bitrate to start with, your encoding will result in a source so close to the original that it is almost guarantee that extra passes will not improve the quality.

I think the challenge really comes with low bitrates: 2500 / 3000 / 3500 (I have a lot of them, because I like to keep all the extras (althouh at Half D1 and Half Space and at least two audios - English and Spanish). In these cases you are suggesting go with filters instead of extra passes, but you have not performed the same kind of experimentation and so, you do not have the same kind of hard data to support your recommendation.

I would like to see a similar analysis with a VBR of 2500, just for 1+1, 1+2 and 1+3, with and without filters (I use the ones that come with CCE 2.6). I think this kind of test will be better to measure the impact of extra passes and/or filters on output qulity, when it is really needed.

Hopefully, the conclusion will be in line with your recomendation, and all of us will just encode with 1+1 passes, so saving a lot of time and energy

Pablo

Sir Didymus
24th November 2004, 15:35
Originally posted by pg55555
It is realy a very interesting and helpfull analysis, and it will surelly prompt me to reduce my standard 1+4 passes to a faster 1+2 passes.


Hi Pablo :)
Please consider I clearly wrote: "Every one may draw the conclusions more suitable for him/her. Concerning myself, I will continue to use my method with CCE that is the following...", so every one is free (as it should) of performing the process using as many passes as he/her want...


But, not offense intended, it is not a little biased? What I mean is, making the comparison with a cell with a VBR average of 4250 it is not a way to assure that there will be little gain with extra passes? If you have a decent bitrate to start with, your encoding will result in a source so close to the original that it is almost guarantee that extra passes will not improve the quality.

Really ? I just choose 4250 because it is very well matching with most of the last backup I did...


I think the challenge really comes with low bitrates: 2500 / 3000 / 3500 (I have a lot of them, because I like to keep all the extras (althouh at Half D1 and Half Space and at least two audios - English and Spanish).

Are you really actually placing >4 hours of video in a DVD ? Do you really have DVD titles with video encoded at 2500 kbit/s ?


In these cases you are suggesting go with filters instead of extra passes, but you have not performed the same kind of experimentation and so, you do not have the same kind of hard data to support your recommendation.

Good point. What you say is true. But please take into account that I clearly described the method as the one I use, and that every one should follow his/her own view on the subject; so please consider the recommendation I gave as directed to myself...


I would like to see a similar analysis with a VBR of 2500, just for 1+1, 1+2 and 1+3, with and without filters (I use the ones that come with CCE 2.6). I think this kind of test will be better to measure the impact of extra passes and/or filters on output qulity, when it is really needed.

Lot of work to carry out, but I agree some further testing could be useful...


Hopefully, the conclusion will be in line with your recomendation, and all of us will just encode with 1+1 passes, so saving a lot of time and energy

Never given to any body in such a direct terms the recommendation of using always 1+1 passes; again Pablo, please consider I did not intend to give strong suggestions or recommendations. I only wanted to show with ARGUMENTS that the statement "more passes is always better" should be taken as an opinion and not as a fact.

Cheers,
SD

pg55555
24th November 2004, 17:41
Sir Didymus

I understood your original post, and I know the restrictions of your findings and recommendations.

You did a very good job (as usual), and as in all good scientific research you were very clear detailling the conditions and limitations of the testing.

I also agree with your assestment
I only wanted to show with ARGUMENTS that the statement "more passes is always better" should be taken as an opinion and not as a fact.
My point (and at this stage is just an opinion)is that if you have a good bitrate to start with, it is going to be difficult that extra passes, whose purpose is to better distribute the available bitrate, will have a measurable possitive effect.
But if you are bitrate hungry (2500-3000 bps), maybe (and this is just an opinion based in logic)those extra passes would improve the output.
Of course, the measurement of this improvement is another question.

I do not understood you methodology (this SSIM thing), but after re-reading your post a new doubt come to my mind:
You mention a "similarity index". I suppose what you are measuring is how "similar" it is the encoded clip to the original.
If so, I´m not sure it is the correct tool.
What I mean is, from a mathematical point of view, if you start with a source with an average bitrate of 6500, and yur output average bitrate is 4550 (compression 70%), wouldn't be the most similar result the one that just compress each frame by that 70% ratio? And the output would look just fine
But if you have a bitrate hungry output (say VBR avrage of 3000, a 46% compresion), the most similar result would also be the one that compress all the frames to the same 46%. But in this case, the fast action frames would look bad, as they need more bitrate. So, here comes the bit allocation optimization of CCE, which will improve the output quality, but the similaty would be lower. And this bitrate allocation among frames would improve by each passes (at least in the first passes) until a point in which it would start oscillating around an optimun by a small quantity (here I´m acepting your point of not mathematical convergence, but after having some improvement)
Do you really have DVD titles with video encoded at 2500 kbit/s ?
I do have videos with 2800 / 3200 bps for the main movie and 850 for the extras (Half D1). Remember, I keep all the extras an two audios (if they are 5+1 they are 350 MB each). I also use the "low bitrate" and "Ultra low bitrate" filters respectivelly

Sir Didymus
24th November 2004, 18:46
Originally posted by pg55555

My point (and at this stage is just an opinion)is that if you have a good bitrate to start with, it is going to be difficult that extra passes, whose purpose is to better distribute the available bitrate, will have a measurable possitive effect.

Ok. This is an opinion. At least in one single case (V1C3 of Kill Bill V1 - PAL - R2) it has been verified it is so...


But if you are bitrate hungry (2500-3000 bps), maybe (and this is just an opinion based in logic) those extra passes would improve the output. Of course, the measurement of this improvement is another question.

Pablo, I want to state explicitely my full respect to your opinion. But sorry, I do not see the logic on the basis of your opinion; maybe it is based on your experience, or on your feelings, [or on your hope] ? but not on the logic...


I do not understood you methodology (this SSIM thing), but after re-reading your post a new doubt come to my mind:
You mention a "similarity index". I suppose what you are measuring is how "similar" it is the encoded clip to the original.
If so, I´m not sure it is the correct tool.

Never told to anyone to believe in SSIM. It is just a metric for evaluating a similarity index, that actually have many limitations. Nevertheless it is a method, and it could be used by everyone having the time to use it. Get a look to the original paper (I gave a precise reference in my previous post). I found it a nice and very interesting reading!!!. By the way, if you or anyone else have some other OBJECTIVE method of comparison, please share the info!!!


What I mean is, from a mathematical point of view, if you start with a source with an average bitrate of 6500, and yur output average bitrate is 4550 (compression 70%), wouldn't be the most similar result the one that just compress each frame by that 70% ratio? And the output would look just fine

Really? I don't think so, in MPEG2 there are GOPs composed by I frames, P frames and B frames. A very smart strategy for the bitrate reallocation should be already present in a smart encoder, even for what you consider "small" reductions. MPEG2 is a standard for compressing very strongly a video stream, and it is amazing to remind that also the original titles, available in DVDs, are already, in general, very strongly compressed, if compared to an uncompressed stream...


But if you have a bitrate hungry output (say VBR avrage of 3000, a 46% compresion), the most similar result would also be the one that compress all the frames to the same 46%. But in this case, the fast action frames would look bad, as they need more bitrate. So, here comes the bit allocation optimization of CCE, which will improve the output quality, but the similaty would be lower. And this bitrate allocation among frames would improve by each passes (at least in the first passes) until a point in which it would start oscillating around an optimun by a small quantity (here I´m acepting your point of not mathematical convergence, but after having some improvement)

What you say are opinions. Maybe they are true, maybe they are not...


I do have videos with 2800 / 3200 bps for the main movie and 850 for the extras (Half D1). Remember, I keep all the extras an two audios (if they are 5+1 they are 350 MB each). I also use the "low bitrate" and "Ultra low bitrate" filters respectivelly
Ok. That demonstrates it could be useful to do some tests with bitrates ~3000...

Cheers,
SD

TheSeeker
24th November 2004, 19:04
Originally posted by Sir Didymus


Ok. That demonstrates it could be useful to do some tests with bitrates ~3000...

Cheers,
SD

I think thats all he really wanted. He just wants to see this same test performed on a movie that has had alot of compression applied, to see if in fact more passes has more of an impact on the resulting quality if alot of compression is applied as opposed to lighter compression. Personally I think that the tests will find that the same is true, 1+2 or 1+3 being the optimal settings for passes. But again that is MY OPINION. Not intended as a statement of fact in the least. I must admit though I am interested to see the results of such a test. And I dont have the time or expertise that you do Didy to perform such a test and accurately portray the results.

Sir Didymus
24th November 2004, 19:09
Originally posted by Boulder
To get an even better comparison, do a test with OPV, Q value set so that the average bitrate is as close to the multipass avg bitrate as possible.

Tooting my own horn;)

Hi! Carried out some little more testing... Maybe again nice to share the results...

Well, conditions, source title, and method is the same of my previous post; tested OPV using Q values in such a way that the output FILE SIZE was near as much as possible to the target size. For comparison, the size of the m2v files generated using VBR (passes 1+1 ... 1+9) was the following:


test_1+1.m2v 140.774 KB
test_1+2.m2v 140.946 KB
test_1+3.m2v 140.978 KB
test_1+4.m2v 140.956 KB
test_1+5.m2v 140.959 KB
test_1+6.m2v 140.961 KB
test_1+7.m2v 140.960 KB
test_1+8.m2v 140.963 KB
test_1+9.m2v 140.962 KB


With OPV Q28 and OPV Q29 (min bitrate and max bitrate set as for the multipass test):


OPVQ28.m2v 142.268 KB
OPVQ29.m2v 139.126 KB


Obtained SSIM values are:

OPV Q28 Average SSIM= 0.981885 Std. Dev. = 0.011593
OPV Q29 Average SSIM= 0.981467 Std. Dev. = 0.011678


Given just a quick looking to the produced m2v files...; think you may have some good reasons for tooting your horn... [just this damn Q factor is actually an integer... grrr...]

SD

Boulder
24th November 2004, 19:20
Originally posted by Sir Didymus
With OPV Q28 and OPV Q29 (min bitrate and max bitrate set as for the multipass test):


OPVQ28.m2v 142.268 KB
OPVQ29.m2v 139.126 KB


Obtained SSIM values are:

OPV Q28 Average SSIM= 0.981885 Std. Dev. = 0.011593
OPV Q29 Average SSIM= 0.981467 Std. Dev. = 0.011678


Given just a quick looking to the produced m2v files...; think you may have some good reasons for tooting your horn... [just this damn Q factor is actually an integer... grrr...]

SD

Hehe, I told you:D There is a reason why I choose constant quality encoding whenever it's possible. However, you might want to run a test, doing a sizing pass using the vaf file from the OPV encode and set the avg bitrate to the desired value. I've seen some reports at the DVD2SVCD forums that it might produce even better results and the size would be accurate.

The fact that Q is an integer is actually a blessing since it requires very little time to find the correct value. With TMPGEnc it can take a very long time because the factor is a float and it isn't even close to linear.

Sir Didymus
24th November 2004, 19:22
@jorel & every one interested in the files

I uploaded the following files to a server adopting dynamic links, so please send to me, via PM, in the next five days, a suitable e_mail address; I will reply with a working link where to download the files; sorry for the trouble...

Files are related to the performed test. Please consider that (except the first one, which is quite small) all the files are very BIG, so just dowload what you really need...

* Uncompressed images + xls files (zip):
* Source_V1C3.m2v (197283286 byte)
* test_1+1.m2v (144151828 byte)
* test_1+2.m2v (144347056 byte)
* test_1+9.m2v (144344604 byte)

They will be available just for 5 days (until 29.11.2004 01:40:05 PM CET).

@Wmansir:
I hope I am not infringing any of the doom9 rules; if so please feel free to edit my post or to delete the whole post...
NOOO NOT THE WHOLE THREAD...
:D

SD

Sir Didymus
24th November 2004, 20:10
Ok. The last test for this week is with Procoder (on the same cell, with the same bitrate values); please consider in this case the encoder results are NOT frame by frame comparable to the ones generated by CCE, since the GOP structure of the produced m2v file is (in general) different: not useful to compare an I frame of CCE with a B frame of Procoder (and viceversa). Also please consider the source cell is PAL, and someone claim Procoder + PAL is especially good...

Anyway, (thanks to robot1, who allowed DVD-RB to use Procoder) the obtained filesize is:


Procod.m2v 140.984 KB


and the resulting SSIM values are:


Average SSIM= 0.984904 Std. Dev. = 0.010796


Maybe it is worth to comment that it is true that the average SSIM is higher than the one obtained with 9 passes using CCE (meaning that, in average the similarity index of the encoding produced by Procoder is higher than CCE) but the std. dev. is also higher, and this means that the SSIM values have a wider spread around the average.

I would say people loving Procoder have their valid arguments... Especially in comparisons with encodings performed using CCE VBR with an high number of passes: in this case the disvantage of Procoder in terms of the long time it takes for its maximum-two-passes-and-that's-it vanishes...

SD

TheSeeker
24th November 2004, 20:14
So Didy could you explain the significance of the OPV test you performed and the observations you might make on it? What I really want to know is this: From the tests you have performed so far do we conclude that OPV shows better mathematical accuracy (Per SSIM) than multi pass at LOW compressions. And multipass is better at HIGH compreesion ratios, (again only mathematically, according to SSIM)? What Im really asking for IS YOUR OPINION, on when OPV might be a good idea and when multipass might work better, given the SSIM values you have observed in your thorough testing. Again Im aware that your opinion will be based on mathematical observations that you have made using SSIM (Which may or may not be an objective testing apparatus).