Quantcast Bitrates: Testing CQmatic Versions - Page 12 - digitalFAQ.com Forums [Archives]
  #221  
08-20-2003, 10:50 AM
girv girv is offline
Free Member
 
Join Date: Sep 2002
Posts: 108
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to girv
Setting the min bitrate to 0.57 * average-bitrate will likely increase it above the old standard 300kbps, right? So will that not reduce video quality since more bits are used to encode frames that dont need them and the overall CQ will have to be lower? Or did I miss something again?

/girv
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
  #222  
08-20-2003, 10:55 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 girv
Setting the min bitrate to 0.57 * average-bitrate will likely increase it above the old standard 300kbps, right?
Yes, but usually the MIN bitrate fluctuates around 400-500Kbps, so CQ calculations are more accurate than when lowering it to 300.
Unless you're using the ULBR, where the average is very low, and also the MAX bitrate, then you can go way low on the MIN too.

-kwag
Reply With Quote
  #223  
08-20-2003, 11:33 AM
DKruskie DKruskie is offline
Free Member
 
Join Date: May 2003
Location: Michigan
Posts: 147
Thanks: 0
Thanked 0 Times in 0 Posts
I just got done with this a couple minutes ago, and after looking at the log I'm kinda confused at what the correct cq should be ? Should I choose 80.18 or 80? I also see it chose the the same cq more than once. Here's the log

http://www.kvcd.net
CQMatic Version 1.1.12a
Copyright Softronex Corporation, 2003.
All rights reserved.
Time: 11:57:48 Date: 08/20/2003
Ready!
Project: C:\DVD\Kwag070803.tpr

Creating: CQMatic.tpr

C:\DVD\Kwag070803.m1v
Project resolution: 352x240
Execute.
Movie Time: 108
Average Bitrate: 903
Prediction Only mode
Executing Prediction Phase...
Process started at 11:58:43
On 08/20/2003
CQ set for prediction
Setting up initial sampling.
Using CQ of 60.00
Prediction cycle #1
Encoder started...
Process time: 2.55 minutes.
Encoder end.
File size difference = 1.387796
Low fence: 60.000000
High fence: 90.000000
Last CQ = 60.00
Current CQ = 83.27
CQ difference = 23.267738
Using CQ of 83.27
Prediction cycle #2
Encoder started...
Process time: 2.52 minutes.
Encoder end.
File size difference = 0.846521
Low fence: 60.000000
High fence: 83.267738
Last CQ = 83.27
Current CQ = 71.63
CQ difference = 11.633873
Using CQ of 71.63
Prediction cycle #3
Encoder started...
Process time: 2.18 minutes.
Encoder end.
File size difference = 1.243023
Low fence: 71.633865
High fence: 83.267738
Last CQ = 71.63
Current CQ = 77.45
CQ difference = 5.816940
Using CQ of 77.45
Prediction cycle #4
Encoder started...
Process time: 2.47 minutes.
Encoder end.
File size difference = 1.163526
Low fence: 77.450806
High fence: 83.267738
Last CQ = 77.45
Current CQ = 80.36
CQ difference = 2.908463
Using CQ of 80.36
Prediction cycle #5
Encoder started...
Process time: 2.22 minutes.
Encoder end.
File size difference = 0.993907
Low fence: 77.450806
High fence: 80.359268
Last CQ = 80.36
Current CQ = 78.91
CQ difference = 1.454231
Using CQ of 78.91
Prediction cycle #6
Encoder started...
Process time: 2.17 minutes.
Encoder end.
File size difference = 1.140644
Low fence: 78.905037
High fence: 80.359268
Last CQ = 78.91
Current CQ = 79.63
CQ difference = 0.727119
Using CQ of 79.63
Prediction cycle #7
Encoder started...
Process time: 2.48 minutes.
Encoder end.
File size difference = 1.061152
Low fence: 79.632156
High fence: 80.359268
Last CQ = 79.63
Current CQ = 80.00
CQ difference = 0.363556
Using CQ of 80.00
Prediction cycle #8
Encoder started...
Process time: 2.22 minutes.
Encoder end.
File size difference = 1.024969
Low fence: 79.995712
High fence: 80.359268
Last CQ = 80.00
Current CQ = 80.18
CQ difference = 0.181778
CQMatic complete!
Total minutes of process: 18.80
Process ended at 12:17:31
On 08/20/2003


David
Reply With Quote
  #224  
08-20-2003, 11:41 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 DKruskie
I just got done with this a couple minutes ago, and after looking at the log I'm kinda confused at what the correct cq should be ? Should I choose 80.18 or 80?
It's 80. I've updated CQMatic to 1.1.12b, to show the final CQ ( by Phil's request )
I'll upload it in a little while.

-kwag
Reply With Quote
  #225  
08-20-2003, 11:46 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
Uploaded!
http://www.kvcd.net/CQMatic-1.1.12b.exe

-kwag
Reply With Quote
  #226  
08-20-2003, 06:25 PM
DKruskie DKruskie is offline
Free Member
 
Join Date: May 2003
Location: Michigan
Posts: 147
Thanks: 0
Thanked 0 Times in 0 Posts
The cq of 80 was to big. CQ 80=836,318=816mb
I'm going to try testing it again and see if I get the same value.

David
Reply With Quote
  #227  
08-20-2003, 06:44 PM
vhelp vhelp is offline
Free Member
 
Join Date: Jan 2003
Posts: 1,009
Thanks: 0
Thanked 0 Times in 0 Posts
Hi DKruskie.. evening all

Quote:
The cq of 80 was to big. CQ 80=836,318=816mb
I'm going to try testing it again and see if I get the same value.
If you mean testing CQM prediction, it should still remain the same. I've
done this a few times w/ other CQM versions - - so no need to.. really

Also, I would imagine that if you re-encode again, w/ same params, you'll
end up w/ the same FinalSize.. I would assume

-vhelp
Reply With Quote
  #228  
09-01-2003, 09:47 PM
J-Wo J-Wo is offline
Free Member
 
Join Date: Nov 2002
Location: Toronto, Canada
Posts: 454
Thanks: 0
Thanked 0 Times in 0 Posts
Is there a big in 1.2.0 where cqmatic says "CQ_VBR set for prediction" when in fact it's set for CQ? It also does prediction in CQ as I specified in my project file... Just noticed this now and not sure if it's always been there or just a fluke I spotted.
Reply With Quote
  #229  
09-01-2003, 09:52 PM
vhelp vhelp is offline
Free Member
 
Join Date: Jan 2003
Posts: 1,009
Thanks: 0
Thanked 0 Times in 0 Posts
@ j-wo..

I noticed this too, a couple of weeks ago, but thought it was a bug that
was already cought, or I missed the explanation. I ignored it since

-vhelp
Reply With Quote
  #230  
09-01-2003, 10:21 PM
J-Wo J-Wo is offline
Free Member
 
Join Date: Nov 2002
Location: Toronto, Canada
Posts: 454
Thanks: 0
Thanked 0 Times in 0 Posts
hmm well I think something was messed up in my project file, cause my prediction was going bonkers. I'm encoding episodes of Babylon 5, which normally settle at CQ 63. But the prediction was going up to CQ 80 then back down, but got stuck at CQ 63.01. Anyway I remade my project file from scratch and now it seems to be working fine (i.e. it says CQ set for prediction). I'll write back if I have any more problems
Reply With Quote
  #231  
09-17-2003, 10:03 AM
nicksteel nicksteel is offline
Free Member
 
Join Date: Nov 2002
Posts: 863
Thanks: 0
Thanked 0 Times in 0 Posts
quote="kwag"
It's a piece of cake, and your aspect will always be correct
Here's what you do.
Open your .d2v as "Video Source" in TMPEG. Got to "Crop" and clip out your black borders, leaving only your Film area.
You'll get this:

Now look at the top values on the top left. In my case, it's 718x358. So take those values to Moviestacker, and enter them in the "Film pixel" text boxes.
Now read the "Resize" values that MS gives you, and enter them in TMPEG's "Video Arrange Method" pixels text boxes.
You'll have this:

That's it
Now your movie will have the aspect it's supposed to have, perfectly


Given the above, what modifications do I make to my AVS, either using GripCrop or using values from Movie Stacker in the script?
Reply With Quote
  #232  
09-17-2003, 10:21 AM
J-Wo J-Wo is offline
Free Member
 
Join Date: Nov 2002
Location: Toronto, Canada
Posts: 454
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by nicksteel
Given the above, what modifications do I make to my AVS, either using GripCrop or using values from Movie Stacker in the script?
In order to enter the "Film Pixels" into MS, you have to deselect "Use Gripcrop" on the first tab of MS. When you then look at the script that MS creates, you'll notice there are no GripCrop or GripBorders lines. Instead you'll see something like:
Code:
Bilinearresize(528,480,0,0)
Addborders(0,0,0,0)
These are the lines you would then use in replace of GripCrop. The first line would go where GripCrop used to go, and the second goes where GripBorders used to be. Good luck!
Reply With Quote
  #233  
09-17-2003, 10:45 AM
nicksteel nicksteel is offline
Free Member
 
Join Date: Nov 2002
Posts: 863
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by J-Wo
Quote:
Originally Posted by nicksteel
Given the above, what modifications do I make to my AVS, either using GripCrop or using values from Movie Stacker in the script?
In order to enter the "Film Pixels" into MS, you have to deselect "Use Gripcrop" on the first tab of MS. When you then look at the script that MS creates, you'll notice there are no GripCrop or GripBorders lines. Instead you'll see something like:
Code:
Bilinearresize(528,480,0,0)
Addborders(0,0,0,0)
These are the lines you would then use in replace of GripCrop. The first line would go where GripCrop used to go, and the second goes where GripBorders used to be. Good luck!
Understand. Thanks!
Reply With Quote
  #234  
09-23-2003, 09:27 AM
nicksteel nicksteel is offline
Free Member
 
Join Date: Nov 2002
Posts: 863
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by kwag
Quote:
Originally Posted by vhelp
Yes, fair enough

But, at the moment, TMPG doesn't have a good method for working out
those AR issues, and resizing. That's one of my key reasons for the
.d2v-VFAPI route in my encoding projects
Sure it does
That's why I posted the link I did above
It's a piece of cake, and your aspect will always be correct
Here's what you do.
Open your .d2v as "Video Source" in TMPEG. Got to "Crop" and clip out your black borders, leaving only your Film area.
You'll get this:

image

Now look at the top values on the top left. In my case, it's 718x358. So take those values to Moviestacker, and enter them in the "Film pixel" text boxes.
Now read the "Resize" values that MS gives you, and enter them in TMPEG's "Video Arrange Method" pixels text boxes.
You'll have this:



That's it
Now your movie will have the aspect it's supposed to have, perfectly
Quote:

I did some playing around over the weekend w/ .d2v and AR diggiting, but
I did have some problems with maintaing the same level of quality that
I got than my regular .d2v-VFAPI route.
Maybe I'll do some more playing around later
Just follow the above, as it can't fail
Also, take a look at the link I posted before, as it's a good discussion as to why it's done that way.
Quote:

Kwag.. plus, you have to understand and accept other peoples prefered mechanism for source feeding into TMPG.. if it works for them in their given system.. that's what counts.
Sure, I'll accept any mechanismm, as long as it's correct
And the mechanism I just explained, is the correct method, as suggested by the experts such as SansGrip and shh (designer of FitCD) specifically for that reason. Any other method is not correct, unless you arrive at the same resize as described above, which is "the" correct method for correct aspect ratio.

Edit: The same method is used for feeding TMPEG with an .avs script. After the "Film pixels" are found, the .avs is written, and then the .avs is opened with TMPEG instead of the .d2v
-kwag
On the tmpgenc screen, you show crop checked. Is this necessary when I use moviestacker to produce script statements using the tmpgenc pixels as you have described in other posts?
Reply With Quote
  #235  
09-23-2003, 10:46 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 nicksteel

On the tmpgenc screen, you show crop checked. Is this necessary when I use moviestacker to produce script statements using the tmpgenc pixels as you have described in other posts?
No, because the script produced by Moviestacker takes care of the cropping automatically, so it's already feeding the exact film pixels to TMPEG.

-kwag
Reply With Quote
  #236  
09-23-2003, 11:22 AM
nicksteel nicksteel is offline
Free Member
 
Join Date: Nov 2002
Posts: 863
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by kwag
Quote:
Originally Posted by nicksteel

On the tmpgenc screen, you show crop checked. Is this necessary when I use moviestacker to produce script statements using the tmpgenc pixels as you have described in other posts?
No, because the script produced by Moviestacker takes care of the cropping automatically, so it's already feeding the exact film pixels to TMPEG.

-kwag
Great! I am processing with the MA optimum script at present. The CQMatic passes are going much faster than with the non-MA with 2.08 and I look forward to seeing the results. I assume motion should be smoother with the MA script.
Reply With Quote
  #237  
09-23-2003, 07:26 PM
nicksteel nicksteel is offline
Free Member
 
Join Date: Nov 2002
Posts: 863
Thanks: 0
Thanked 0 Times in 0 Posts
Running MA optimum script with Avisynth 2.52

AddBorders(16, 33, 16, 33) gives error when TMPGEnc starts:

Evaluate: Unrecognized exception!

Is there a dll containing Addborders() different for 2.52. Only this function gives a problem.

Trying to use:

LoadPlugin("c:\video\dlls\GripFit_preview.dll")

gives me a error saying that it is not an Avisynth 2.5 plug in.

I'm trying to use movie stacker data into my avs.
Reply With Quote
  #238  
09-23-2003, 08:36 PM
jorel jorel is offline
Invalid Email / Banned / Spammer
 
Join Date: Aug 2002
Location: Brasil - MG - third stone from the sun
Posts: 5,570
Thanks: 0
Thanked 0 Times in 0 Posts
hey nick,
use the word "latexxx" in the search and you get
the gripfit yv12 for avisynth 2.5x!


thanks again(tons) latexxx!
Reply With Quote
  #239  
09-24-2003, 01:07 AM
CheronAph CheronAph is offline
Free Member
 
Join Date: Feb 2003
Location: Espoo, Finland
Posts: 494
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via MSN to CheronAph
Here, http://www.nic.fi/~lhahne/GripFit_YV12.zip
__________________
¨¨°º©©º°¨¨°º©CHERONAPH©º°¨¨°º©©º°¨¨
Reply With Quote
  #240  
07-07-2004, 10:44 AM
Fluffbutt Fluffbutt is offline
Free Member
 
Join Date: Apr 2004
Posts: 189
Thanks: 0
Thanked 0 Times in 0 Posts
Excuse me for opening an old topic (I am playing with the two versions of CqMatic (12xx & 13xx), and was looking for comparisons when I came across this.

Kwag - is there anyway to get those crop values (in the picture, the 704x272) in tmpg without using moviestacker?
__________________
|
Meeow!
Reply With Quote
Reply




Similar Threads
Thread Thread Starter Forum Replies Last Post
Bitrates: Question About Latest Versions Of CQMatic/CalcuMatic gretagun Video Encoding and Conversion 2 01-22-2005 05:06 PM
Bitrates: How to use CQMatic? mistermickster Video Encoding and Conversion 1 08-29-2003 06:47 AM
Bitrates: Beta Testing with same source and same settings Krassi Video Encoding and Conversion 57 08-19-2003 03:39 PM
Bitrates: KDVD bitrates with CQMatic nicksteel Video Encoding and Conversion 10 08-06-2003 08:44 AM
CQMatic: Too many filters with differant versions! Max Powers Video Encoding and Conversion 32 07-29-2003 11:21 PM

Thread Tools



 
All times are GMT -5. The time now is 07:03 AM  —  vBulletin © Jelsoft Enterprises Ltd