Quantcast CQ vs. CQ_VBR ... Very Interesting... - Page 5 - digitalFAQ.com Forums [Archives]
  #81  
12-26-2002, 06:52 AM
ARAGORN ARAGORN is offline
Free Member
 
Join Date: Oct 2002
Posts: 50
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by kwag
Quote:
Originally Posted by black prince
Hey Kwag,

The file prediction forumla used to be:

Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * (MPEG sample file size * .98 )

Now it's this:

Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * (MPEG sample file size )

Which is correct

-black prince
The second one. The prediction is now so accurate that you don't need the .98 multiplier
Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * MPEG sample file size

-kwag

Hi kwag!

Are you sure the formula is so accurate? I've encoded a film which is 80 min long with lbr template. The file size is 555MO with cq 90. The predicted filesize is 9,88. If i use your formula i've got a result of 617M0. But if i use this:

Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * (MPEG sample file size * .90 ) the result is: 555,75MO!!!

Do you think the factor could be different for each resolution?

ARAGORN
Reply With Quote
Someday, 12:01 PM
admin's Avatar
Site Staff / Ad Manager
 
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
  #82  
12-26-2002, 09:43 AM
black prince black prince is offline
Free Member
 
Join Date: Jul 2002
Posts: 1,224
Thanks: 0
Thanked 0 Times in 0 Posts
@All,

There is some improvement using High in motion search
This goes back to an old issue about the algo Tmpgenc's using
to detect scene changes between frames at the macro block level it
seemed to work, but at the pixel block level it would ignor this
due to smoothing from TemporalSmoother and now FluxSmooth.
Try encoding without smoothing and see if it improves more
With these short comings and others the Frankencoder project was
born. (Maybe). Tweaking Q-Matrix may not have produced solutions
but defining the problem further could help in seeking answers. The
progress being made is excellent (file prediction, new GOP, 704x480
fitting on 1 CD, etc.) Don't give up now. Maybe Tmpgenc's
developer could shed some light for a solution on this problem

-black prince
Reply With Quote
  #83  
12-26-2002, 09:57 AM
black prince black prince is offline
Free Member
 
Join Date: Jul 2002
Posts: 1,224
Thanks: 0
Thanked 0 Times in 0 Posts
@Kwag,

Just finished encoding full movie using 704x480, GOP=1-12-2-1-24,
for 2 CD(800MB ea) with CQ=75 and there are NO!! Gibbs effects.
I threw Blockbuster noise back in with a variance of .3 and Flux.
Tmpgenc's motion search is set to High and I'm using Clip Frame.
Audio is 128kb and thanks to file predictor the video filled the rest of
the CD's. Picture quality is incrediable!!!! Maybe with higher
CQ the encoder has more bitrate to work with Any way, I'm
switching to this resolution at least for 2 CD's.

-black prince
Reply With Quote
  #84  
12-26-2002, 10:53 AM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by Jellygoose

kwag, try this script for blockbuster with cq mode and your matrix... I'm sure it will give you better results...

Blockbuster( method="noise", detail_min=1, detail_max=10, variance=1, seed=1 )
That's exactly the parameters I have been using. I even lowered the "detail"max" to 5 and the variance to .5 and the results are worse. The problem is the movie I tested is 138 minutes. That is a very long movie with a lot of movement. So as it is, the bit rate is already pretty marginal without any filters. When I add blockbuster, that margin is gone because I have to lower CQ value in order to target the same predicted sample, and then things start to look bad. That's why I mentioned that if you have more bits to play with, then you can use Blockbuster to your advantage. If the movie is already too long, any noise filters will just drop your quality below that minimum treshold and the overall picture quality will suffer.

-kwag
Reply With Quote
  #85  
12-26-2002, 10:53 AM
Jellygoose Jellygoose is offline
Free Member
 
Join Date: Jun 2002
Location: Germany
Posts: 1,288
Thanks: 0
Thanked 0 Times in 0 Posts
Hi kwag!

can you actually compare the Q-Level of different resolutions? because lower quality has a lower Q-Level too, as far as my tests prove...

Is that right?
__________________
j3llyG0053
Reply With Quote
  #86  
12-26-2002, 10:56 AM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by ARAGORN
Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * (MPEG sample file size * .90 ) the result is: 555,75MO!!!
With the new GOP and formula, remove the factor.
The formula is:

Code:
Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * MPEG sample file size
-kwag
Reply With Quote
  #87  
12-26-2002, 11:24 AM
ARAGORN ARAGORN is offline
Free Member
 
Join Date: Oct 2002
Posts: 50
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by kwag
Quote:
Originally Posted by ARAGORN
Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * (MPEG sample file size * .90 ) the result is: 555,75MO!!!
With the new GOP and formula, remove the factor.
The formula is:

Code:
Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * MPEG sample file size
-kwag
Hi kwag
I know that but if i do this the result is not good. There is 62MO of difference between the encoded film and the result with the new formula. I'm using the new gop and Sampler last version. To have the good result I have to multiplying the mpeg file size by .9... Sorry to insist

ARAGORN
Reply With Quote
  #88  
12-26-2002, 12:22 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Hi ARAGORN,

I'm not sure what's going on there , because I've already made over 4 different CQ encodes with the above formula, and every time I'm hitting < 1% predicted size to final size no matter what resolution I use

-kwag
Reply With Quote
  #89  
12-26-2002, 12:35 PM
ARAGORN ARAGORN is offline
Free Member
 
Join Date: Oct 2002
Posts: 50
Thanks: 0
Thanked 0 Times in 0 Posts
Kwag,

What are your exacts settings in cq mode: does enable padding is check?
And what about P and B picture spoilage? Are they set to 0 or not?

I don't know if that could make a difference in the accuracy of the prediction ?
Reply With Quote
  #90  
12-26-2002, 02:44 PM
bman bman is offline
Free Member
 
Join Date: Apr 2002
Posts: 356
Thanks: 0
Thanked 0 Times in 0 Posts
Hi all !!!
I'm confused !!!
what is the most updated method or script for file prediction ?!?
Anyone please ?!!!
bman
Reply With Quote
  #91  
12-26-2002, 03:50 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by ARAGORN
Kwag,

What are your exacts settings in cq mode: does enable padding is check?
And what about P and B picture spoilage? Are they set to 0 or not?

I don't know if that could make a difference in the accuracy of the prediction ?
It shouldn't make any difference what you set your parameters, as long as your settings remain identical after calculating final size with the sample. That means that after you have your final CQ value, just remove the "Sampler()" line from your .avs script and encode your movie. I always check "enable padding". I am currently using picture spoilage of 0 and B spoilage of 20. These are the default values. I noticed that if I change those values, I have to re-calculate CQ, and when I do it's the same result no matter what I set the spoilage. Changing the spoilage values only changes the CQ encoding curve.

-kwag
Reply With Quote
  #92  
12-26-2002, 04:32 PM
apoc apoc is offline
Free Member
 
Join Date: Dec 2002
Posts: 9
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by kwag

It shouldn't make any difference what you set your parameters, as long as your settings remain identical after calculating final size with the sample. That means that after you have your final CQ value, just remove the "Sampler()" line from your .avs script and encode your movie. I always check "enable padding". I am currently using picture spoilage of 0 and B spoilage of 20. These are the default values. I noticed that if I change those values, I have to re-calculate CQ, and when I do it's the same result no matter what I set the spoilage. Changing the spoilage values only changes the CQ encoding curve.

-kwag
Hi kwag,

Which template did you use ?
My tests are better with CQ_VBR that CQ

--
apoc
Reply With Quote
  #93  
12-26-2002, 05:00 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by apoc
Hi kwag,

Which template did you use ?
My tests are better with CQ_VBR that CQ

--
apoc
I've tried 352x240, 528x480 and 704x480. All with CQ encoding and KVCDs Q Matrix.

-kwag
Reply With Quote
  #94  
12-26-2002, 05:06 PM
jamesp jamesp is offline
Free Member
 
Join Date: Jul 2002
Location: Chelmsford, UK
Posts: 130
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by apoc
Quote:
Originally Posted by kwag

It shouldn't make any difference what you set your parameters, as long as your settings remain identical after calculating final size with the sample. That means that after you have your final CQ value, just remove the "Sampler()" line from your .avs script and encode your movie. I always check "enable padding". I am currently using picture spoilage of 0 and B spoilage of 20. These are the default values. I noticed that if I change those values, I have to re-calculate CQ, and when I do it's the same result no matter what I set the spoilage. Changing the spoilage values only changes the CQ encoding curve.

-kwag
Hi kwag,

Which template did you use ?
My tests are better with CQ_VBR that CQ

--
apoc

apoc,

Strange. I'm testing on some of my Tv Captures and CQ set to 80-85 (704x576) puts 1 Hour Widescreen on one CD at far better quality than CQ_VBR at the same filesize. For me, this is definately the way to go.

Jim
Reply With Quote
  #95  
12-26-2002, 05:21 PM
apoc apoc is offline
Free Member
 
Join Date: Dec 2002
Posts: 9
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by jamesp

apoc,

Strange. I'm testing on some of my Tv Captures and CQ set to 80-85 (704x576) puts 1 Hour Widescreen on one CD at far better quality than CQ_VBR at the same filesize. For me, this is definately the way to go.

Jim
I've just encoded The Game : 2 hours CQ_VBR=8 (KVCDx3) 1 CD
Very nice quality ... My first tests with CQ give me lot of macroblocks.

dunno why

I use KVCDx3 template and I replace CQ_CBR with CQ and change the resolution.

--
apoc
Reply With Quote
  #96  
12-26-2002, 05:47 PM
m0rdant m0rdant is offline
Free Member
 
Join Date: May 2002
Posts: 137
Thanks: 0
Thanked 0 Times in 0 Posts
I'm getting very confused now =)

What is the concensus? Is CQ better with high resolution (704x480 and x3) and CQ_VBR with low resolution (352x240/480)?

Should we keep using filters?

Just when I think I've got a handle on the KVCD thing everything changes...

I'm not complaining...just losing track.
Reply With Quote
  #97  
12-26-2002, 06:02 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by m0rdant
I'm getting very confused now =)

What is the concensus? Is CQ better with high resolution (704x480 and x3) and CQ_VBR with low resolution (352x240/480)?

Should we keep using filters?

Just when I think I've got a handle on the KVCD thing everything changes...

I'm not complaining...just losing track.
Hi m0rdant,

Try your prediction samples with all the filters. Blockbuster, FluxSmooth, etc. Then if you see that the sample's quality is not so good, remove only the blockbuster "noise". Leave FluxSmooth() and LegalClip(). I always use them. So far it seems that CQ is beating the crap out of CQ_VBR

-kwag
Reply With Quote
  #98  
12-26-2002, 06:38 PM
m0rdant m0rdant is offline
Free Member
 
Join Date: May 2002
Posts: 137
Thanks: 0
Thanked 0 Times in 0 Posts
I'm using DVD2SVCD for encoding/predicting...

CQ prediction doesn't seem as acurate with DVD2SVCD. I tried the first disk of Lord Of The Rings and got a file that was 200megs too big.

CQ_VBR seems to come in on target or just below though.

What I'm wondering is, if CQ is kicking the crap out of CQ_VBR, how did we get started on CQ_VBR and what has changed to make CQ the better choice again?

We started with CQ and then went to CQ_VBR and the "plus" templates, which were recomended over the originals...and now Blockbuster is no longer in favor (for me it seems to help with getting solid black colors)...but at some point each of these was viewed as way better than the old way.

At any rate, the work is appreciated, even if its overwhelming me a bit at the moment.
Reply With Quote
  #99  
12-26-2002, 06:50 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by m0rdant
I'm using DVD2SVCD for encoding/predicting...

CQ prediction doesn't seem as acurate with DVD2SVCD. I tried the first disk of Lord Of The Rings and got a file that was 200megs too big.
Don't use DVD2SVCD for prediction with the new GOP. It just won't work. The algo we've developed is extremely accurate, and it's not the same algo used in DVD2SVCD. We'll have to wait until DVD2SVCD integrates the new method.
Quote:

CQ_VBR seems to come in on target or just below though.

What I'm wondering is, if CQ is kicking the crap out of CQ_VBR, how did we get started on CQ_VBR and what has changed to make CQ the better choice again?
We didn't have any kind of file prediction way back when we started to do comparison with CQ and CQ_VBR. CQ_VBR seemed to create better quality, maybe with the older versions of TMPEG used at the time. But now that we have tools to measure different encoding techniques by keeping a target size constant between different encoding schemes, we clearly see the difference
Quote:

We started with CQ and then went to CQ_VBR and the "plus" templates, which were recomended over the originals...and now Blockbuster is no longer in favor (for me it seems to help with getting solid black colors)...but at some point each of these was viewed as way better than the old way.
NO WAY, Blockbuster is the bomb . But I explained this earlier: If you have enough bits available that you can add Blockbuster "noise", go ahead, and you'll have excelent quality. If you don't have spare bits, that is your encoded sample has a very low CQ for your final target size and the quality is good but "borderline", anything you introduce that will lower your final average bit rate will degrade your quality. In this case, don't use blockbuster.
Quote:

At any rate, the work is appreciated, even if its overwhelming me a bit at the moment.


-kwag
Reply With Quote
  #100  
12-26-2002, 07:03 PM
m0rdant m0rdant is offline
Free Member
 
Join Date: May 2002
Posts: 137
Thanks: 0
Thanked 0 Times in 0 Posts
Ok, that makes some sense to me =)

I can go back to doing things manually, I just like the ease of DVD2SVCD...support for it here is one of the things that brought me back to using KVCD settings.

The prediction in DVD2SVCD seems to work very well with CQ_VBR and the new gop settings, just not with CQ.

Well, I'll try doing things the old "hands on" way for my next encode.
Reply With Quote
Reply




Similar Threads
Thread Thread Starter Forum Replies Last Post
Avisynth: Interesting results with YlevelsS supermule Avisynth Scripting 2 08-06-2006 11:59 PM
Avisynth: Interesting ASharp phenomenon... audioslave Avisynth Scripting 12 10-23-2003 06:36 AM
Interesting info about the Luminance Level in CCE digitalize Video Encoding and Conversion 0 04-28-2003 12:29 PM
A couple of interesting links.. kwag Off-topic Lounge 0 12-31-2002 03:47 PM
KVCD: Interesting poll found kwag Video Encoding and Conversion 2 12-31-2002 02:44 AM

Thread Tools



 
All times are GMT -5. The time now is 07:25 PM  —  vBulletin Jelsoft Enterprises Ltd