Verdict on 528x480: CQ mode essentially the same as CQ_VBR (perhaps with less Gibbs and a tiny bit blockier), except for very fast motion, where CQ mode is vastly superior.

Now testing 352x480.

Here's an illustration of the problem I was talking about earlier wrt 352x480. It's not as bad this time (probably because I used "high quality" motion searching), but you can clearly see a difference in the area I highlighted. In the CQ_VBR version, the blocks are there but are sort of "rounded" and are less regular and defined than in the CQ version. It doesn't look too bad in the screenshot, but when it's moving there's a very noticible difference in blockiness between the two. I also find the CQ version a bit blurry.

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

I think I take from this test that -- at least with this fast-action, low-luma material -- CQ mode is suitable for 528x480 and 704x480 but not for 352x480. The same probably applies for 352x240.

Hi SansGrip,

Could you make one more test from that clip, but use a higher MIN value. Maybe 600 :idea: Maybe CQ doesn't respect MIN as much as CQ_VBR, and that's the reason for the higher blockiness. Just something that poped in my mind right now :roll:

-kwag

It's better, but still blockier. Also at least with this material there's a significant increase in file size.

And now we're going to a neighbour's house for a few drinks. I'll probably pop back on when I get back to see if there's any more developments, but I don't expect I'll be doing any more testing until the 27th when we get back from visiting parents-in-law 8O.

The way I see it is that CQ is allocating more bits on high frequency components, and that's why we see less artifacts. Then maybe on "not so long" movies, we have an advantage with CQ, and longer movies CQ_VBR wins. Maybe it's not resolution related. Maybe Quantization Matrix related :?: . The KVCD Q. Matrix was heavily tested on CQ_VBR, not on CQ :roll: :idea:

-kwag

Yes, that could explain why we see more DCT blocks in low-frequency areas. I think the reason that it works better at higher resolutions is because when you increase the resolution, DCT blocks become less apparent. When you're zooming a 352x480 up to full-screen you really notice those over-smoothed low-frequency parts.

It shouldn't really make any difference what length the movie is, since a GOP is always the same size (at least with scene-change detection unchecked).

Well, it's definitely Q matrix-related. If we were to reduce the quantization on the low frequencies we'd see fewer blocks.

I'd say if we contemplate a switch to CQ, the first thing we should do afterwards is revisit the Q matrix and reduce the low-frequency quants. Of course for the moment we could recommend CQ for 528x480 and above, then once we've settled on a Q matrix tuned for CQ we could probably use it for every template.

That's not to say that each template/resolution couldn't have a different VBR method and Q matrix... 8O

Either that or I've had too many beers 8).

Hehe :D
I think the best thing to do is to "Revisit the matrix" Not "The Matrix Revisited" 8O :mrgreen:
It would be a pain to have different GOPs and matrices for different resolutions. I'd hang myself :lol:
No, you haven't had enough beers yet :wink:

-kwag

I figured I'd post this in here since everyone is following it ;).

We'll be leaving tomorrow about 8:30am to visit my parents-in-law for Christmas, so I won't be back at the testing until the 27th or 28th. Hope you all have a good Christmas and many advances are made in my absence. I expect to find you all fitting Saving Private Ryan onto one disc at 704x480 by the time I get back :mrgreen:.

Hey have fun SansGrip :lol:
Merry Christmas to you and your family.

Over here in Puerto Rico, we're all having fun eating "Lechon Asado" (Roasted Pig. Mmmm! ), Morcillas ( You don't want to know!, something from the insides of the pig ), "Guineitos fritos" ( Sort of cooked bananas in vinager and olive oil, onions, etc ), "Arroz con gandules" ( Rice and a kind of bean ), Rum and lots Beer, and I feel like a pig :mrgreen:

Later!,
-kwag

I didn't realize anyone was still awake :).

Sounds absolutely delicious (don't worry about morcillas -- I've been known to eat haggis in the past ;)). I wish I could look forward to such eating instead of turkey! :)

HI guys! 8O

wow, now this threat has made some progresses since yesterday. I'm pretty sure we found something of interest here...

I made several more tests, and here are my results... I don't have a space to upload the samples yet :? but that will surely follow...

Sample #1:

KVCDx2 704x576 PLUS w/ KWAG Matrix @ CQ_VBR 5.8

--- 11,374 KB --- Average Q-Level : 6.55 Q-Peak : 19.2 !!


Sample#2:

KVCDx2 704x576 PLUS w/ Default Matrix @ CQ_VBR 5.8

--- 11,371 KB --- Average Q-Level : 7.09 Q-Peak : 20.24 !!


Sample#3:

KVCDx2 704x576 w/ Default Matrix @ CQ 57

--- 11,391 KB --- Average Q-Level : 5.28 Q-Peak : 5.64 !!


Sample#4:

KVCDx2 704x576 w/ KWAG Matrix @ CQ 61 !!!

--- 11,416 KB --- Average Q-Level : 4.62 Q-Peak : 4.80 !!!


Conclusion:

CQ Mode beats the s### out of CQ_VBR regarding the Q-Level. Overall performance looks better too. Using KWAG Matrix w/ CQ Mode gives me the oppurtunity to increase CQ Level somehow...
I'm sure there is a more optimized Matrix for CQ mode too, so that those blocks disappear in low bitrate areas...

:D Hehe kwag... we struck on gold again here... as far as i can see...

Right Now I am ripping the first DVD of LOTR Special Extended edition... I want to fit the whole movie on 2 CDs using 528x576 resolution with the Kwag Matrix and CQ mode...

I'll let you know about the results

ok, I did my first samples of Lord Of The Rings Estended Edition.

This is what the first DVD of this beast will look like on ONE CD-R!!
I don't know why I can't upload them right now, but I've some problems...
Will do that later!

Sample#1 :

--- 11,941 KB --- 528x576 CQ Mode 71,25 w/ KVCDx2 Matrix... Avg. Q: 2.64 Peak: 2.72


Sample#2 :

--- 12,002 KB --- 704x576 CQ Mode 63 w/ KVCDx2 Matrix... Avg. Q: 4.29
Peak: 4.44


Both Samples look great in my eyes... Is there any difference between the KVCDx2_PLUS Matrix and the KVCDx3 Matrix??

:lol: I kinda miss the enthusiasm about this right now... no replies since this morning... Well I guess everybody's filled up with turkey and sleeping in his TV Chair... :wink:
C'mon kwag get up! :o there's work to do here, remember SansGrip wants Saving Private Ryan in 704x480 DVD quality on a single floppy disc :D

No there is not. All PLUS use the same Q. Matrix :wink:

-kwag

Let's see some samples Jellygoose :D :twisted:

-kwag

sorry about this taking so long... I just signed up for lycos webspace, but they somehow need alot of time to activate the account... I'll post the links here as soon as i uploaded the samples...

Hi Kwag,

Great News!!! :D File prediction seems to still be accurate using CQ and
new GOP. I tested Vanilla Sky, 8161 seconds, 195,684 frames, at CQ=55,
and audio = 64kb, for 1 CD. The test result was 732,142,261 and
the actual video encode file size is 726,994,559. WOW 8O That's very
close for accuracy. This movie took ~12hrs with the following script:

LoadPlugin("E:\DVD Backup\2 - DVD2SVCD\MPEG2DEC\MPEG2DEC.dll")
LoadPlugin("E:\DVD Backup\2 - DVD2SVCD\BlockBuster\BlockBuster.dll")
LoadPlugin("E:\DVD Backup\2 - DVD2SVCD\LegalClip\LegalClip.dll")
LoadPlugin("E:\DVD Backup\2 - DVD2SVCD\Sampler\Sampler.dll")
mpeg2source("D:\Temp\movie.d2v")
LegalClip()
BilinearResize(672,352,10,0,700,480)
#BlockBuster(method="noise", variance=.5, seed=1 )
TemporalSmoother(1,2)
AddBorders(16,64,16,64)
LegalClip()

Fast search was used in Tmpgenc. The movie quality is excellent, but
there are noticable Gibbs noise around people and objects both near
and in the background. This a distinct improvement over CQ_VBR. :D
Also, note that Blockbuster's noise is commented and TS(1,2) was
added for compression. I have never gotten a 704x480, 136 minute
movie on 1 CD with good quality. 8O I think your on to something big :mrgreen:


-black prince

Hi black prince,

You might want to add the Blockbuster "Noise" line back, but this time with a lower variance ( .3 to .4 ) :wink:
Also you might want to play with the detail_min and detail_max values. :wink: :wink:
I'm pretty sure we're all switching to CQ after we fully optimize the low frequency stuff :wink: :wink: :wink:

-kwag

great... here's the sample from LOTR 528x576 resolution. I'm currently encoding that one, and the sample looks promising.
See for yourself
http://mitglied.lycos.de/catch22tx20...576cq72.28.m1v

that first DVD of the movie is gonna fit on one CDR with a 128kb audio track... it's 103 mins long... :wink:
(sorry about the 10MB file... hope ya'll have a good connection over there! )

kwag I don't have a clue how to compensate for those low frequency blocks, but when you come out with an optimized Q-Matrix I'll definetely start testing it!! :D

I'm on 256Kbps DSL, so no prob here :D
Downloading... 8)

Edit: 2 minutes to go ....

-kwag

....... waiting.... for ..... reaction.... :) :mrgreen:

This is what I think of that sample:
8O 8O 8O 8O 8O 8O 8O 8O 8O 8O
8O 8O 8O 8O 8O 8O 8O 8O 8O 8O
8O 8O 8O 8O 8O 8O 8O 8O 8O 8O
8O 8O 8O 8O 8O 8O 8O 8O 8O 8O
8O 8O 8O 8O 8O 8O 8O 8O 8O 8O
8O 8O 8O 8O 8O 8O 8O 8O 8O 8O

That looks like a DVD 8O . Actually I've seen worse DVD encodes 8O
I renamed the file from .m1v to .mpg so I could see the correct aspect and play it on WinDVD. "A>W>E>S>O>M>E" I have no better words to describe that :D 8)

-kwag

:D That's YOUR work kwag!!

We should go on testing and try to get rid of those low frequency blocks...
I'll let you know when the complete movie is done and if it fits... right now it's a little too big for 24%... well we'll see. I used "Sampler ()" and this formula for the prediction :

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

was that the latest for the new GOP?

Not anymore!, it's OUR work :D You bet!. I'm running some tests analyzing the low frequency spectrum of mpeg files :wink:
Your formula is correct. Make sure you're using 1-12-2-1-24 for your GOP.

-kwag

that's what the sample is using.

BtW: That GOP kicks ass... :twisted: far better than the old ones we had!

Hey Kwag,

I included Blockbuster noise with a variance of .3 and detail_min=1,
detail_max = 10 (defaults) in my script. I changed Tmpgenc's
motion search to motion estimate search (fast). The picture
quality was just as great as before with dark areas showing no
blocking and the time to encode went from ~12hrs to ~10hrs.
I tested the above changes using 1 minute clips, but with
detail_min & max, I don't know what improvements in the
video to look for :?: This will probably come together before
SansGrip gets back to testing. I know you'll have a Q-Matrix for
us to play with before then :mrgreen:
This is very exciting. :D :D :D :D

-black prince

:( Bad news, as for the prediction... The Encoding process is at 88% and right now it looks like it's gonna be over the predicted size by 28 MB.. 8O

:oops: I just noticed what I did wrong... no wait... I'm confused now... I used "Sampler ()" is that correct or do we need to use any values? sampler took 100 mini samples, but didn't we only use 60 ? I also divided through 25 instead of 24 because framerate is 25 for PAL? what did I do wrong w/ the predicition?

Ok it's 21 MB over... That I can't even fit with overburning... Well I'll try again... Would just be good to know where my error was... any comments?

You're 100% correct :lol: . A little later tonight, as I'm currently cranking out a new Q Matrix :mrgreen:
Will let you know. I'm still running boocoo tests on low frequency domains right now. :wink:

-kwag

Seems you didn't apply the formula correctly. It's this:
Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * (MPEG sample file size )

-kwag

Does this apply to PAL too? We have 25 as framerate as you know...

Maybe something interesting :

The filesize is smaller with high quality motion search than estimate fast :

CQ_VBR=8 544x576 85 seconds

estimate fast : 8193968 bytes
high quality : 7955238 bytes

diff : 238730 bytes (2.91%) :)

here is the script :

LegalClip()

Crop(8, 74, 692, 428)

BilinearResize(512, 320)
FluxSmooth()
Blockbuster( method="noise", detail_min=1, detail_max=10, variance=.5, seed=1 )
AddBorders(16,128,16,128)

LegalClip()

with CQ=64

estimate fast : 8104839 bytes
high quality : 7924119 bytes

diff : 180720 bytes (2.2%)

--
apoc

Yes. It applies to PAL too, because we're still creating a MAX frames per GOP of 24. So it's the same formula :)

-kwag

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 :wink:
Predicted MPEG size = (( Total frames/MovieTimeInMinutes)/24) * MPEG sample file size

-kwag

After hours of trials and trials with different matrixes, modification, changes and whatever, I have come to the conclussion that the DCT blocks can not be removed without damaging the quality of the picture. No matter how low I change the low frequency values that work with the matrix coefficients at the low frequency domain, the DCT blocks still show. 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. If we're trying to squeeze a very long movie on a CD-R, then we're better off just using FluxSmooth filters but not Blockbuster, because the available bits are so scatered throughout the picture that trying to add the noise to kill the DCT blocks just lowers the overall quality of the picture. So that's it :!:
Here's the final 704x480 sample. This is what will go into one CD-R with audio at 112Kbps from the movie K-19 which is 138 minutes long. Here's the script I used:

And here's a 33 second sample, cut out of the ~11MB prediction sample:
http://www.kvcd.net/final.m1v

Enjoy :wink: ,
-kwag

:? mmmm I don't know kwag... I think here's still room to play around, with YOUR matrix. I encoded LOTR now, with "High Quality" Motion Search, and the quality is even better than the last sample! I'll upload it later today.

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 )

I'll try to do some tests with anime - maybe (CQ + HQ search) gives less mosquitoes...