Hey cool black prince :D
We're in sync today :lol: I just finished the movie "The Siege", a 116 minute film with the new KVCDx2 704x480 PLUS ( just for the hell of it :lol: ) to see how it came out. I was able to encode with a CQ_VBR of 8.5 which just barely made it quality wise. The video stream came out to 704,050KB, so I'm encoding now the audio at 128Kbps. The total will be 812MB. Looks pretty damn good for an action film and fitted on a single CD-R. Here's a cut-out of the actual .m1v : http://www.kvcd.net/clip.m1v
How do you like that for a 704x480 movie on a single CD-R :?:
Here's the script I used:

LoadPlugin("C:\encoding\MPEG2DEC.dll")
LoadPlugin("C:\encoding\fluxsmooth.dll")
LoadPlugin("C:\encoding\blockbuster.dll")
LoadPlugin("C:\encoding\legalclip.dll")
mpeg2source("K:\SIEGE\VIDEO_TS\siege.d2v")
LegalClip()
FluxSmooth()
Blockbuster( method="noise", detail_min=1, detail_max=10, variance=.5, cache=1024 ) # Apply noise if complexity is <= 10%.
LegalClip()

Masked and resized in TMPEG to 672 X 448 for the correct aspect.
This is way cool, I think I'm not going to do 352x240 resolutions anymore. If I can do this at 704x480, then a more complex movie I'll do at 528x480 (x3) or 352x480. :lol:

-kwag

Kwag,

The BlockBuster noise should not be present at the borders because the AddBorders line is AFTER the blockbuster stuff (in the script you posted).

The only thing after the AddBorders in your script is the LegalClip, maybe the TMPGEnc mask is an "illegal" black and that's what makes a difference.

Hi GFR,

But the TMPEG mask is already in the encoder, and that's applied after any external filters :!: , so that shouldn't be the case. If I remove Blockbuster "Noise" method, then the file size drops. So this is what causes the larger file sizes. If you don't apply the mask in TMPEG, with the Blockbuster "Noise" method the file is much larger, so the mask is cutting out something Blockbuster is feeding TMPEG.

-kwag

Hi Kwag,

Kwag wrote:
Try KVCDx3 (528x480) and post your results. I would love to fit most
movies on 1 CD using this template. :D It's seems to look better start-
ing at CQ_VBR 25. I got an extra 100MB with your process for the last
encode. 8)

Thanks

-black prince

sorry if you already mentioned this kwag, but which template do I use to get the quality you got with the m1v file?

That sample was encoded with the KVCDx2 704x480 PLUS and the methods mentioned here. As black prince said, with the x3, it will probably look better because the resolution is slightly lower so more bit rate is available to the movie. There won't be that much loss of sharpness dropping to 528x480, but for the same material, a higher CQ_VBR can be used and then the result is higher quality.

-kwag

Hi Kwag,

I've playing around with DCT-filter for compression without effecting
picture quality. Just wondered what your opinion was about using this
filter. :) Here the link for further discussion:

http://www.kvcd.net/forum/viewtopic....ht=compression

-black prince

Hi Kwag,

Is this a filter that works only with avisynth 2.5 only or can it work with
avisynth 2.07 :?:

-black prince

Hi Kwag,

For avisynth 2.07 which filter do I use? DCTFilter.zip or DCTFilter_YUY2.zip :?:

thanks

-black prince

Hey Kwag,

I used DCTFilter_YUY2 and the results were disappointing. :cry: The settings
used were DctFilter(1,1,1,1,1,1,.5,0). It had almost no effect in reducing
file size. FluxSmooth vs TemporalSmoother, FS() increased file size
while TS(1,2) reduced it. Blockbuster sharpen is an obvious no no. It
increased file size significantly. I was looking for a filter with good
compression (decrease file size) and has little or no effect on picture
quality. Do you have any other ideas to reduce file size :?:

-black prince

Hi black prince,

I haven't experimented with those filters yet. :roll: Will let you know as soon as I can test that.

Here's something else that's puzzling.
I need people to try something that doesn't make sense to me at all 8O
This is what I just tried. As you know, the new GOP is 1, 36, 3, 1, 36 which i theory, the file size will (should!) be smaller that using a smaller GOP. Right? WRONG 8O 8O How? Why?

I was tinkering with the GOP today, and I encoded a sample by accident with a GOP of 1, 26, 3, 1, 26 and the file size was smaller 8O
So I decided to do a test. I started to encode samples with max number of frames per GOPs from 6 to 24, and this is what I found. Using a CQ_VBR value of 11.34, the value I was using for a test encode with the x3, here are the results:

1,6,3,1,6 = 9,034KB
1,7,3,1,7 = 9,035KB
1,8,3,1,8 = 8,039KB
1,9,3,1,9 = 8,039KB
1,10,3,1,10 = 8,039KB
1,11,3,1,11 = 8,036KB
1,12,3,1,12 = 8,832KB
1,13,3,1,13 = 8,820KB
1,14,3,1,14 = 8,821KB
1,15,3,1,15 = 8,818KB <------- Optimal
1,16,3,1,16 = 9,442KB
1,18,3,1,18 = 9,444KB
1,24,3,1,24 = 9,539KB


So PLEASE, could some of you do some tests and see if you come up with the same results I have? If you do, and the results are the same, this means that the optimal GOP of 1,15,3,1,15 is the "Sweet Spot" for our Q. Matrix, which yields the smallest file size. Apparently because the number of B frames is 3, instead of the standard 2 used in the standard MPEG GOP. This is about 2MB smaller per 100 second sample, compared to the GOP we had before. This test was done with the masking method talked about in this thread and with the x3 template. I will try the same thing on the LBR and see if it works the same, or if there's another optimized GOP for that resolution. If these numbers are correct, this means a much higher CQ_VBR value than before, for the same amount of film.

Thanks,
-kwag

Are you sure Flux increased the file size? By definition a smoother should reduce it. Do you mean the file size reduction with Flux was less than with TS? That I could believe :).

Especially the borders, since they're as low-detail as you can get. I forgot to mention this -- you should always do AddBorders as one of the last filters in the script (definitely after Blockbuster).

I do it in this order:

Though you can smooth before resizing if you think that's better.

As far as TMPGEnc's internal resize producing smaller files, I'd say it must be because it results in a softer image even than Avisynth's bilinear. There's no other explanation that occurs to me right now.

Hi SansGrip,

I think it all had to do with the Blockbuster spraying noise on the black areas :lol:
When you mask the borders inside TMPEG, that makes black borders pitch black :D , and then the noise generation that is fed by Blockbuster via AviSynth is focused only inside the picure area. I can't really tell the difference between TMPEG's internal resize to AviSynth's bilinear resize as far as quality difference. At least on high resolutions like 704x480.

-kwag

I can't decide if this makes sense or not. Theoretically, of course, a big GOP means fewer I-frames which means a smaller final size. I have a hunch that these results might have something to do with the picture degradation introduced -- perhaps that many P- and B-frames has an adverse effect on motion estimation?

It will be very interesting to know if this is source- and/or resolution-dependent. I'm going to run some tests on American Pie right now :).

As does using AddBorders at the end of the script :). The advantage of cropping borders/resizing/filtering/adding borders all within Avisynth is that the filters only have to run on the actual picture area, which should speed things up.

Edit: How much a difference it makes depends on the source size and the final encoding size. If the source is 720x480 and the encode is 352x240 you'll notice a big speed drop if you don't resize before running smoothers, etc.. If the encode size is closer to the source, say 704x480, there won't be much difference at all.

Yes, that's absolutely right, but then why such a great file size difference when I use TMPEG's internal resize with masks :?: That's what I can't figure out. If it was 300 or 400KB, that fine, but the difference is between 1 to 1.5MB for a 100 second sample :?

Edit: Even at 704x480 there is a huge difference 8O

-kwag

Right now I'm running some max GOP tests. Could you try cropping the borders, resizing, filtering, and adding borders in Avisynth, and compare it to just cropping borders and filtering in Avisynth then resizing and adding borders in TMPGEnc?

I'd be interested to know the result of that specific test.

That really is enormous. You might have struck gold again here Kwag old boy :mrgreen:.

:mrgreen: :mrgreen: :mrgreen: Hey, you're the one who revolutionized the mpeg industry by pumping noise into the encoder to eliminate DCT blocks. I'm just giving your filters a haircut around the ears :lol: :lol: :lol:

Preliminary results
 

Encoding with KVCDx3 in TMPGEnc 2.58 non-plus. CQ_VBR 25. No masking/resizing in TMPGEnc.

Max GOP 15: 17.4mb
Max GOP 24: 16.3mb
Max GOP 36: 16.1mb

As you can see, with external resizing I obtain expected results, at least with this 1m25s clip. I'll try again with lower CQ_VBR and edit.

CQ_VBR 10:

Max GOP 15: 7.82mb
Max GOP 24: 7.91mb
Max GOP 36: 7.72mb

8O I'll leave analysis until later. Now I'm going to test internal resizing/letterboxing.

Max GOP 36, CQ_VBR 25:

External resize/letterbox: 16.1mb
Internal resize/letterbox: 16.3mb

:?:

Max GOP 36, CQ_VBR 10:

External: 7.72mb
Internal: 7.81mb

Can't duplicate your results here, kwag :?.