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!!! :lol:

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

ARAGORN

@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

@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!!!! :mrgreen: 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. 8)

-black prince

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

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?

With the new GOP and formula, remove the factor.
The formula is:

-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 :D 8)

ARAGORN

Hi ARAGORN,

I'm not sure what's going on there :roll: , 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 :roll:

-kwag

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 :roll: ?

Hi all !!!
I'm confused !!!
what is the most updated method or script for file prediction ?!?
Anyone please ?!!!
bman

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 :cry:

--
apoc

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

-kwag

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 :cry:

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

--
apoc

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. :wink: So far it seems that CQ is beating the crap out of CQ_VBR :D

-kwag

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.

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.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 :wink: NO WAY, Blockbuster is the bomb :lol: . 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. :wink:

-kwag

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.

@Kwag and SansGrip,

Problems with file predictor for CQ greater than 80. Seems Tmpgenc opens the bitrate
flood gates beyond this point and throws off the formula by a large amount. File
prediction told me the new is CQ 85.871 (14.4% too small) after using CQ 75. Then
test file size jumps from 21,406,846 (CQ=75) to 32,826,302 (CQ=86). File prediction
then suggests using new CQ 66.67 ??????? I’m using 2 CD’s with a target video size
of 1,425,637,201. The file size formula works with no problems using CQ_VBR.
Maybe CQ reacts differently at various CQ settings to controlling bitrates.

Also, is there a KVCD template for 528x480 using CQ or how can I
change KVCDx3 to use CQ.

Finally, has SansGrip compared 704x480 to 528x480 resolutions for
CQ with same target file. I think movie length and resolution are the
major factors for high picture quality using CQ. For example, if you must use
1 CD (800MB) and you video target file size is 700MB then a long
movie (2+hrs) will not have the best quality using 704x480 as it
would with 528x480 or 352x480. :)

Thanks


-black prince

just change it black prince... my LOTR Sample is made that way, you can download it from the third page of this thread or so...

Hi Kwag,
" I also confirmed SansGrip's findings that adding Blockbuster "Noise" just makes the quality worse. I believe there is a treshold point to use Blockbuster. If there is enough bit rate available for an encode, then we can use Blockbuster "noise" method to our advantage. "

Does the above statement apply to CQ_VBR mode (KVCD-Plus--704x480)? What about KDVD (Full-D1)?

Side issue: Is DVD Patcher only applicable to Mpeg-2? If not, we can "fool" those standalone DVD player which does not like KVCDx3 then.

Thanks for the Mini-HowTo kwag!

8) I just found out another interesting thing.
Using TemporalSmoother(2,2) even for DVD-Rips is not too bad of an idea! Try it out, it gives a little more compression than the value 2,1 and the thing that is strange to me is : Q-Level decreases from 2.66 w/ TempSmooth 2,1 to Q-Level 2.64 w/ TempSmooth 2,2.

Regarding visible differences I can't give you a lot of testing because my eyes aren't that good. I don't see a difference, only that of course the higher the value, the smoother the image... that's not necessarily a bad thing i guess.... :wink:
Try it out...

TempSmooth(2,2) definately gives you more compression. I use that value as a last resort if I need some more compression. However, i feel the picture really suffers at times. Look at skin tones and flat walls, things start to feel a little unnatural. IMHO, temporalsmoother is an amazing filter. Set it to 4 or 5 and see those filesizes shrink like mad. I use it on some cartoon tv captures at 5, it really gives some serious compression then.

Jim

@Kwag and SansGrip,

This time I tried the guide Kwag posted for manual file prediction and
the same thing is happening. At about CQ 80 or greater the file size
takes a huge increase. Again I used 2 CD's for a movie that's 138 minutes
and the manual prediction fails for CQ > 80. Is there anyone else
having this problem :?: :?: :?: :?:

-black prince

Hi All,

Black prince wrote:
I tried KVCDx3 (528x480) as CQ instead of CQ_VBR and the results
were not as good as 704x480 CQ. The Q-Matrix is probably tuned for
CQ_VBR. It did produce a smaller file size, but for 1 CD and 138
minute movie, the CQ_VBR was much better. CQ definately has the
better picture quality given the same file size. I just hope I can solve
my problems with file size prediction :(

-black prince

Hi black prince,

This is the only way we can measure quality of encodings. We can't judge CQ_VBR over CQ if the file sizes are different. Right now, if I make a sample test with CQ_VBR and I make another one with CQ and adjust the value until the size matches that of the CQ_VBR sample, the CQ sample runs rings on quality around CQ_VBR! Every time :D

-kwag

Same here.... I encoded Lord Of The Rings yesterday at 528x576, with a 128kb audio track, and this is the best DVD backup i have ever made. actually the best I've seen so far :lol: ...
well right now I'm doing another one, at 544x576 and it looks as if it would come out even better. I'm able to use almost the same CQ (only decrease by 1.2), and this way the movie will even look more sharp...

more to come... :wink:

hey all, I've been testing my butt off :lol: I finally put Pearl Harbor (~3 hrs) on one cd with the the latest LBR template and had great results.

I used CQ = 70 (much less artifacts than CQ-VBR)
min bitrate - 300
max bitrate - 1000
spoilage- p-0 b-10

avg. bitrate (viewed with bitrate viewer) is ~500kbps

LoadPlugin("D:\encoding\MPEG2DEC.dll")
LoadPlugin("C:\encoding\fluxsmooth.dll")
LoadPlugin("C:\encoding\LegalClip.dll")
AviSource("D:\PEARL_HARBOR_DSC1\VIDEO_TS\PEARL_HAR BOR_d2v-vfapi.avi")
ConvertToYUY2()
LegalClip()
BicubicResize(336,168,0,0.6,0,0,720,480)
TemporalSmoother(2,2)
fluxsmooth()
legalclip()
AddBorders(8,36,8,36)

I'm much happier with precise bicubic resize at 352x240 it's more sharp than bilinear but not too sharp like Lanczos. Good results with the double noise filters too- I tried Unfilter but there were white lines on the right and left sides. Also Blockbuster made the file size grow too much.

encoded the audio at 112kbps and after I cut the credits off, final file size 812mb

One big problem though is that the audio gets out of synch. I have a feeling that this might be due to the fact that I disabled padding so that the min. bitrate falls well below 300kbps in spots. I'm going to enable padding and check the audio synch and I'll see if this movie will still fit.

Hi all, hope you had a good holiday. I personally ate three times my own bodyweight of cake and pudding :).

Glad to see lots of testing has been done in my absence, and I'm keen to make some more encodes this evening. I'm not going to try to reply to every message, but I'll address some of the points that jumped out at me.

First, I stand by my assertion that at least with the material I tested, CQ mode works far better than CQ_VBR at 528x480 and above, while CQ_VBR is better for resolutions below that. That said, my final decision on the matter will have to wait until I make more encodes with difference source material :).

As far as the use of Blockbuster goes, kwag is quite right when he says that if you can afford the larger file size, it will improve the quality noticibly wrt to blockiness. If you're trying to cram a very long movie on one disc, however, you need all the bits you can get, and this will almost always mean dropping Blockbuster and jacking up the smoothing. It will also help if you reduce the size of the "actual" frame itself by using overscan blocks left and right, and possibly cropping a little off the top and bottom. The more black, the better. Of course all these measures will compromise quality, but that's unavoidable.

Regarding automating file prediction, I'm going to release a new version of KVCD Predictor once things have stabilized a bit. I'm trying to come up with some ways of automating it further and making it easier to use.

Now to test... 8)

Welcome back SansGrip :D :mrgreen:

-kwag

CQ 68.m1v 6.936 mb
CQ_VBR 21.m1v 7.106 mb

I set max bitrate back to 1150 since 1000 barely made any difference at all.

the cq sample looks a little less "mosquitoey" to me.

I disagree -- I think in fact the opposite is true. Take a look at this framegrab from both versions:

http://www.digitalfaq.com/archives/error.gif

I have outlined the areas where the Gibbs is particularly noticible. In each case, the effect is worse in the CQ version.

For me, this confirms my feeling that CQ_VBR is better at resolutions lower than 528x480, but am still testing that resolution and higher.

What resolution was this SansGrip?

Edit: Never mind, I see it's 352x240.

-kwag

I took the 352x240 originals and cropped the borders, combined into one frame with Avisynth, then pasted that frame to Photoshop and doubled the size for clarity.

I also think the CQ version is more blocky. Look at the cheek of the girl in the bottom-middle of the frame.

wow SansGrip, that was very cool of you to evaluate the two samples and actually post screenshots of the two for comparison 8) :wink: The CQ_VBR sample definitely looks better than the CQ sample in your screenshot.

I wonder if the majority of the frames in the CQ-VBR sample have less Gibbs than the CQ sample :?:

I need to learn how to cap screenshots like that- how'd you do that 8O

thanx,
ren

Well, if you're gonna compare then you might as well do it properly :mrgreen:.

They do. I stepped through most of the frames and only picked that one because it showed the difference most clearly.

First I load each MPEG file into VirtualDub, crop the borders and save as an AVI compressed with the lossless Huffy codec (though you could equally save it as an uncompressed AVI, but it'll be twice the size).

Edit: This step would be unnecessary if there were an Avisynth plugin to load MPEG-1 files. There may well be; I've not looked for one ;).

I then use an Avisynth script like this:

and load the script back into VirtualDub. I can then step through the clip a frame at a time, which is much easier than trying to view one then the other.

If I want to take a "grab" of a particular frame I select "Copy source frame to clipboard" and paste it into Photoshop where I can tweak as necessary and save as an image.

Great, I compared various frames of each sample to each other in Photoshop and the CQ-VBR sample is clearly better.

I learned something else new: the samples look better when I view them with WinDVD rather than Zoom player (I don't know why that is :?: )

Thanks,
ren