Hi SansGrip ,

I'll run a couple of tests to see if I can reproduce that. Maybe just setting the minimum notch area to 8 will solve the problem
Can you make that change and test that same sample and see if you see that red artifact again Just change the two 6's and the 7 on the upper left corner of the matrix to 8 and run that test again on that part

-kwag

Yep, I'll do that as soon as this encode is finished (1h40m) .

I just finished the movie "The Matrix" ( Which I have encoded now around 10+ times for test purposes ), but now with KVCDx3. The results are better that anything I had previously done with that movie .
Here's a minute and a half sample of what the complete 136 minute film looks like on one CD, thanks to your filters SansGrip , the new GOP, prediction, CQ=64, BETA-1 matrix ( Yes, I did it with that one, unless the 8's fix the error you pointed out and I'll have to re-encode again )
http://www.kvcd.net/matrix.cq.beta1mat.sample.m1v

Here's the .avs I used:

-kwag

AviSource("D:\Captures\MSMurders\capture_1.00.avi" ) + AviSource("D:\Captures\MSMurders\capture_1.01.avi" ) + AviSource("D:\Captures\MSMurders\capture_1.02.avi" ) + AviSource("D:\Captures\MSMurders\capture_1.03.avi" )

You can use

SegmentedAviSource("D:\Captures\MSMurders\capture_ 1.avi")

and it will load all four files automatically.

Remember to delete the dummy .avi file if it exists, VirtualDub creates it if you use it for capturing. It's the last file with no video content in it. If you don't delete it, you might get an access violation when using SegmentedAVISource.

@kwag

I still don't understand how you possibly get such high CQ values, ESPECIALLY with a high-action movie like The Matrix at 528x480.

The last encode I did was Jay & Silent Bob -- it's about 97 minutes, low action, at 528x480. Audio 128k (about 85 megs). Using an almost identical script (tried adding/removing BB -- this didn't make much difference), new GOP (1/12/2/1/24), Beta-1 Matrix, CQ of 50 was too much to fit on one disc -- I had to overburn. I am using scripts almost identical to yours and the same methods.

What am I missing here? I'm racking my brain. How do you do it?

What's the aspect ratio of the movie? If there's a lot of black, it compresses very well.

Yes, I know.. it's a widescreen movie, I believe 2.35:1 or 1.85:1.

Using TMPGEnc 2.58 (I heard about some issues with 2.59).

But,

with AVI_IO you don't need to worry about that.

Hey gonzopdx,

Kwag's resize for 528x480 is 496x256 and the movie is widescreen 16:9
letter box to start with. If he cuts out credits and uses heavy softening,
he could raise CQ even higher. The new GOP and Q-Matrix compresses
even more. I usually resize 528x480 to 496x336 and still get a CQ in the
high 50's. On STD 27" TV, Kwag's movie would look somewhat flat,
because of the heavy letterbox.

-black prince

But that's the original aspect for that movie . If I resize to something else taller, people will look streched

-kwag

You guys think we were done with GOP and matrix. Think again :
In theory, a GOP of 1-12-2-1-24 should compress more than 1-12-1-1-24 right , WRONG ( At least with TMPEG in CQ mode ). After reading the previous posts about the small "flashing" effect and always trying to optimize more on the DCT level and artifacts, I ran a test to drop the B frames from 2 to 1, but keeping the size of GOP at 24. Look at the result. I don't even need to circle with red , you should see clearly the difference (You might have to blow up the images):



No filters used here. Only LegalClip(). The funny thing is that with CQ=65 on the 1-12-1-1-24, the file size is actually smaller than CQ=64 with 1-12-2-1-24
Sample file size for 1-12-2-1-24 = 14,430KB
Sample file size for 1-12-1-1-24 = 14,380KB

Would anyone be so kind and try this, to see if I'm still dreaming, or if it's true
Playing back my 1-12-1-1-24 sample, seems to be more smoother and less visible artifacts in the overall picture. Specially the background areas, where there was more movement on stills images.

Edit: This changes each GOP to IBPBPBPBPBPBPBPBPBPBPBPB instead of IBBPBBPBBPBBPBBPBBPBBPBB

-kwag

If the encoder doesn't have enough bits it simply makes macroblocks. This is often not noticible when things are moving fast, but you'll see it clearly if you freeze-frame. Of course, the problem is worse when you use very high resolutions with a low bitrate.

I just did a test encode with The Fifth Element (from AVI), 2h2m, and used a CQ of 64 at 528x480. It's very widescreen, though, probably between 1.85:1 and 2.35:1. This means big borders and lots of compression. I also used fairly heavy smoothing.

Bear in mind that kwag uses two overscan blocks when he resizes, and that makes quite a difference. Try encoding two samples, one with no overscan blocks and one with two overscan blocks. You'll see a significant difference in file size.

The new GOP compresses more but the new Q-matrix compresses less. My last encode dropped from CQ 64 to 58 with the new matrix. This is because it -- by design -- does not quantize low frequencies as aggressively as the old.

Like you I'm suspicious. B-frames are significantly smaller than both I- and P-frames: in my last encode, my I-frames were 13,985 bytes on average, my P-frames were 4,601 and my B-frames were 2,785. Based on that it should be the case that fewer B-frames means much less compression...

It's certainly a very clear difference. But where are those extra bits coming from?

I'll try it right after I run the artifact test (something came up last night)!

Did you encode the whole movie with those settings? I'd be interested to know if prediction still holds true...

Oops..I didn't notice that you used AVI_IO. My bad

@kwag

I ran the artifact test and the problem I highlighted is indeed gone when I use 8 as a minimum. That said, now I see similar artifacts in the left-hand side of the frame.

Using a lot of 8s in a frame has never worked for me -- while theoretically it should give best quality, if you single-step through the frames you'll see serious degeneration in the P- and B- frames...

Kwag, you've created another monster

I did a quick-and-dirty test, and *drum roll*

CQ_VBR file size increased when B frames set to 1 (CQ_VBR value 17,3)

It went from 11,712 to 13219.

CQ file size decreased when B frames set to 1 (CQ value 60)

It went from 6,547 to 6,231.

Uh oh. Looks like this will be another chaotic TMPGEnc test session for you lads.

I only encoded the sampler. There is clearly a better visual experience, at least viewed on the computer. Where are the extra bits coming from I agree with you. I don't know
I'm going to encode 5 minutes with each GOP and see if the file sizes maintain their consistency.

-kwag

Great .