Ignore the 4 B frames Branden. I edited the post.

-kwag

I will volunteer as well if you need it.

__________________
Eat drink and be merry for tomorrow we die

Yes, I tried 8 - 36 and arrived @ 10 for the smallest file size. The clip was from "Planet of the Apes", the original, the "damn dirty apes" scene.

__________________
Christopher
Linux is the body, Unix is its soul

Christopher

At what resolution did you encode to get those results.

__________________
Eat drink and be merry for tomorrow we die

Hey go ahead and start testing black prince
I think the best way is to just use an .avs script WITHOUT any filters. That's what I'm doing right now. Here's my test script:

LoadPlugin("C:\encoding\MPEG2DEC.dll")
mpeg2source("K:\RED_PLANET\VIDEO_TS\red.d2v")
IL = Framecount / 100 # interval length in frames
SL = round(Framerate) # sample length in frames
SelectRangeEvery(IL,SL)

And manually resizing in TMPEG and masking all borders black.
This way we all can use the same method, and eliminate filter variables, etc. The more people that test this, the more accurate the results. What I'm doing is encoding each template with 1, 5823, 3, 1, ( 6,7,8,9,10,11,12,13,14,15,16,17,18 ) and taking note on the file sizes. Ignore the 5823, because the last number is the one that fixes the max number of frames per GOP. So just change the last number on every iteration.

Edit: This is sad, I just ran a test and found out that a different CQ_VBR value gives a total different file size . The same tests I did at 720x480 with a CQ_VBR of ~11, the GOP 1-15-3-1-15 made smaller files than 1-36-3-1-36. But with a CQ_VBR value of 25, the opposite is true If anyone cares to confirm this, post it here. If this is true, a GOP prediction will be necessary for a given CQ_VBR value CQ_VBR is a weird beast
And this is why we are getting mixed results from people. Different CQ_VBR values behave different with different GOP's.

-kwag

Not sad -- more fun!

I believe my test results above confirm this. The second set of tests, at CQ_VBR 10, resulted in different file size differences... If you see what I mean.

Question is: is it determinate?

Ok, here's a postulation based on results reported so far:

1) The ideal GOP size is proportional to the number of pixels in the frame; and

2) The ideal GOP size is inversely proportional to the CQ_VBR.

It should be possible to confirm or refute this via specific tests. I'm busy converting a hundred or so OGG files to MP3 right now, but I will be experimenting more in the morning .

Definitively
My results at 352x240 show exactly the same pattern.
KVCD LBR:
CQ_VBR=50, GOP=1,15,3,1,15 file size = 10,318KB
CQ_VBR=50, GOP=1,36,3,1,36 file size = 9,755KB
CQ_VBR=25, GOP=1,15,3,1,15 file size = 6,580KB
CQ_VBR=25, GOP=1,36,3,1,36 file size = 7,576KB

So it seems there is a "crossover point" where a given CQ_VBR causes no file size difference between different GOPs. From this point, decreasing or increasing CQ_VBR causes a shift in file size, depending on a given GOP. This could be helpful as a center point for file prediction too. Because I believe it's the linear center point of CQ_VBR for the template being used at the moment. Does this sound crazy, or does it make any sense

-kwag

ALL this sounds crazy!
You guys are all crazy! And I love it!

Man, I stop reading this forum for just 3 days (3 DAYS!) and when I came back I found this thread... wow! I just finished reading it, and I'm with a headache now. Great stuff!
I will start some tests too.

Just wanna say one thing: It would be great if we could find the exact numbers of lines to cut with avs. We could crop the exact film area, resize to the target resolution, apply the filters just on this area, and them add the borders necessary to go to 4:3. All this have to be done with the correct AR in mind.
This way the filtering process would be faster, because it'll be applied just on the resized film area (no borders, no black bars). And then we will send to the encoder the formatted 4:3 with true black bars (with no noise, or anything else).
A GUI with a preview of the resized screen from avs would do the job.
Is there any program that do it? Or SansGrip will have to make one?

Cheers!

I've been testing different GOP combos all night with the 528x480 res and the best (lowest filesize/quality) I've found is 1,5823,6,1,8.

edit: sorry for drinking and posting

I don't know if this has been mentioned before, but i think the quality of the source material has something to do with it as well. Using the 544x576 (36 max frames in GOP) template i found that a nice clean DVD rip gave me around 150mb less in size . However, a TV capture and a Divx encode gave me much larger file sizes using the same template. I think the tv capture came out 50mb bigger for 25 minutes.

Jim

I tried to use just tmpgenc crop at VCD resolution and got mixed results - nothing talk about for now.
But I found that, using standard avs without addborders and with center in tmpg I always get a smaller filesize (around 0,5%).

About the GOPs that you are testing. I had the idea that the max GOP size was the sum of all frames, for example: a GOP 1-8-3 would give a size of 1+8+8*3 =33 (+1 if close GOP selected). If so, why to use the same number for P frames and Max GOP ?

__________________
JP

The P frame number seems to be totally unpredictable..you have created a monster, Kwag

My results (resolution 352x288, min=700, max=1800, CQ_VBR=30) from a short clip from a DivX movie "The Cannonball Run". No filters were used, I just cropped, resized and then added borders, all within the script. Q Matrix is the same as in the KVCDx2 PLUS templates, including 3 B-frames.

36 : 6217418
30 : 6311858
25 : 6241102
20 : 6243497
19 : 6079148
18 : 6079148 (!)
17 : 6070782
16 : 6073767
15 : 5812553
14 : 5812553 (!)
13 : 5794372
12 : 5797317
11 : 5585052
10 : 5576328
9 : 5568165
8 : 5564800
7 : 6347137
6 : 6325975
5 : 8271254

Really interesting..it fluctuates at some points. I double-checked a couple of these results and they were exact, I got same results. I'm currently encoding the movie with 8 as the P-frame number. It'll be interesting to see if the quality is any good - I'm putting it on 1 CD.

Hi Kwag,

Tried 528x480 with no filters and here's the results:

CQ_VBR=11 GOP=1,15,3,1,15 file size=9,477,843
CQ_VBR=11 GOP=1,36,3,1,36 file size=9,963,897

CQ_VBR=25 GOP=1,15,3,1,15 file size=18,300,307
CQ_VBR=25 GOP=1,36,3,1,36 file size=17,444,818

Well at least I'm consistant with your results. CQ_VBR=25 and GOP
1,36,3,1,36 decreased file size. As SansGrip explained,
each CQ_VBR has an optimal GOP. IF you choose CQ_VBR=11,
then the best GOP will be 1,15,3,1,15. If you choose CQ_VBR=25,
then the best GOP will be 1,36,3,1,36 and so on. Maybe There
has to be lots and lots of testing

-black prince

Oh boy.

So we should find the "crossover point" for each template? At what GOP? And how does changing the CQ_VBR and GOP affect the file size for any given template?

Now I'm confused .

Please don't introduce any more variables!!

P-frame?? Oh boy oh boy.

GOP = I + P + (P+1)xB
Check yourself with TMPGenc->GOP -> GOP structure

bman

Hi All,

Maybe the way to start is to take a resolution (i.e. 528x480) and
test all (almost all) CQ_VBR for best GOP's. Try this for different
movies (source DVD) and see if there is a corrulation. This would
tell us the best GOP for resolution 528x480 and CQ_VBR=11 is
1,15,3,1,15 or if CQ_VBR=25 choose GOP 1,36,3,1,36 and so on.
I tested a different movie than Kwag, but using the same resolution,
CQ_VBR, and GOP has resulted in similar file size results. There
probably is a similar corrulation between other resolutions for
CQ_VBR and best GOP. There is order even in Chaos!

-black prince

He he he! I only found out because i captured a TV program yesterday and i've been capturing the entire series. When i encoded the file using the 36 gop the file size was larger than it was on my previous encodes, so i used the old template and it was 50mb smaller - all using CQ_VBR 25.

I'm a complete novice at this, but is it possible that when the quality is lower, the encoder is having to encode much more data for all the changes between the main frames the longer the interval is between those frames. These encoded changes look like they take more space than an actual main frame! This would explain my TV capture, as there is always a lot more noise on these than dvd encodes and thus are lower in quality.

Jim