Re: Preliminary results
 

Now make the same samples by removing the resize and add borders from your script, and add under Video arrange method (Center custom size ) and put 528 x 352 and go to "Clip Frame" and "mask" , not clip, your four borders completely framed in black. See what you get now.

-kwag

Re: Preliminary results
 

See my post above for resizing/letterboxing with TMPGEnc. I didn't mask because I already cropped the borders in Avisynth. I'm running another encode now using no cropping in Avisynth and masking in TMPGEnc.

I expect this one to be smaller because I now have black borders left and right, whereas before I didn't. That might be where your difference is coming from...

Edit: Yep, slightly smaller file size due to small black borders left and right. From the look of the clips you posted I'd say you're adding fairly wide borders left and right now, which are hidden by overscan on most analog TVs. My TV doesn't do that, however, and I have to encode right to the edges otherwise I have visible black borders on the TV.

Incidentally, you can obtain the same result within Avisynth by resizing less wide, then using AddBorders to make up the missing width.

Re: Preliminary results
 

I'm only adding 2 overscan blocks for 528X resolutions and above. For 352x I add 1 overscan block. I haven't had a problem with 2 even on my HDTV, but 3 cuts off a little on the sides. But even the samples I encoded resizing with AviSynth, I had the same overscan blocks too. So the number of pixels being encoded was the same.

-kwag

Test results on a fast-action scene, CQ_VBR 25, external resizing/letterboxing:

Max GOP 15: 6.28mb
Max GOP 24: 6.11mb
Max GOP 36: 6.08mb

Re: Preliminary results
 

My TV is a Samsung "extra inch" model, which hides between 6 and 8 pixels left and right depending on the overall luminosity of that scene (brighter = fewer pixels hidden).

Perhaps you were adding noise to the overscan borders too?

Are you using 2 B frames or 3 :?:
All the tests I did were using 3 B frames.

-kwag

Same here -- everything else is standard KVCDx3.

I tested a sample of "Lolita" (black and white) with KVCDx2 with GOP-
I used the traditional method (bilinear resize, add borders) :lol:

edit: I did another test sample at 1,5823,3,1,8 filesize= 13,898kb
-ren

This is bizarre. What am I doing that you're not, or vice versa? :)

Edit: Maybe it's the different template...?

Hi Kwag,

Here my test results for LBR (352x240) CQ_VBR=36.97 movie length = 8465 secs.
Note Bilinear and AddBorder are commented.

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")
mpeg2source("D:\Temp\movie.d2v")
#
LegalClip()
#LanczosResize(336,192)
TemporalSmoother(1,2)
Blockbuster( method="noise", detail_min=1, detail_max=10, variance=.5, cache=1024 )
#AddBorders(8,24,8,24 )
LegalClip()
#
IL = Framecount / 100 # interval length in frames
SL = round(Framerate) # sample length in frames
SelectRangeEvery(IL,SL)

Results:

GOP...........Test file size

1,6,3,1,6 = 9,920,774
1,7,3,1,7 = 9,933,956
1,8,3,1,8 = 8,437,159
1,9,3,1,9 = 8,459,455
1,10,3,1,10 = 8,460,316
1,11,3,1,11 = 9,026,206
1,12,3,1,12 = 8,665,136
1,13,3,1,13 = 8,672,708
1,14,3,1,14 = 8,674,234
1,15,3,1,15 = 9,105,185
1,16,3,1,16 = 9,642,647
1,18,3,1,18 = 9,651,592
1,24,3,1,24 = 8,644,753

The GOP 1,15,3,1,15 had a file size difference of –0.023%. The wanted file size
is 732,280,000. I am not sure what you mean by optimal GOP, but it’s certainly didn’t
produce the smallest test result.


-black prince

Hi black prince,

Yes, I was just talking to Christopher on a PM about this :D , and it seems that there's an optimal GOP for every specific resolution. The GOP 1-15-3-1-15 gave me optimal results on 704x480 resolution. We must make more test and find out if the GOP is not affected by the CQ_VBR value. As Christopher suggested to me on a PM, probably we're going to end up with a GOP prediction system and a file size prediction system ( WOW, This is getting fun now :lol: )
So more tests have to be conducted at various resolutions to find out if we can do this. Probably for zeroing in on a GOP size, some small 10 second samples should be enough. Looking forward to this stuff :mrgreen:

-kwag

Geez i remember when i first came to this site and it was just load the .d2v and audio in tempgenc and selct your template and bam we are done. now we are venturing into predicting gop's wow. I have used tempgenc to resize and used the new gop 1 15 3 1 15 and it looks damn good. The only prob is i have a 50% increase in encode time which is like an additional 4 hours. The additional bit rate is worth it. I am glad your never stop plugging away, always searching for way to increase the quality and playtime. Many thanks go your way.

Branden

Let the new GOP prediction party begin :mrgreen:

Oh, btw heyitsme, every time I read your signature, something pops up in my mind. I would write it like this:
Eat drink and be merry, then get married, then divorce. Re-marry and divorce again. Get screwed in court, for tomorrow we die :mrgreen:

Just kidding :oops: :D

-kwag

If that's what it comes to I can certainly add it to the Predictor ;). However I have a feeling that we'll find an optimal GOP size for each of the templates/resolutions rather than having to adjust the GOP for specific source material.

At least, it would be much simpler that way... :D

I just had the feeling you were going to say that SansGrip :mrgreen:
Let the party begin :lol: To do it manually, it's a hassle, but I can see that definitively a different GOP is needed for each template/resolution.
It's your call :wink: I have a feeling I won't go to sleep tonight until I'm exhausted doing GOP tests :D . I'm off to 7-Eleven to get some beers now :D BRB.... :wink:
Hint: I just tried 1-10-4-1-10 with the 704x480 template and I got a sample size of 10.6MB 8O . With the 1-15-3-1-15, the same sample was 12.776MB and I can't see any quality difference on my monitor. Other values with 4 B frames gave me larger file sizes.

Edit: Drop the idea of 4 B frames. I just took a very close look and there are slight artifacts more visible. So the MAX of 3 B frames should be left alone. It gives better compression than 2, and quality stays the same. The ideal thing is to find the optimal number of P's

-kwag

GOP
 

I have been trying various different GOP structures using 352x480 resolution and have found the following.

One minute clip with external clipping and resizing.....

CQ of 20

GOP 1-36-3-1-36 = 9,151KB

GOP 1-10-3-1-10 = 5,981KB

Difference of (9,151 - 5,699 = 3,170KB :!: )

-Christopher

ROFL :lol: :lol: :lol:

Hmmmm....about the 4 b frames. I have only a 25 inch tv at home. Would it be alright if i changed it to 4 frames as long i am not watching it on a 60 inch hdtv. Would i notice a difference between 3 and 4?

Branden

Hi Kwag and SansGrip,

If your developing an optimal GOP for each resolution, wouldn't it be
easier to post a certain movie with its information (i.e. Widescreen,
minutes, etc.), an avs script you'll be using and let some of us divide
the testing among those willing to get involved. Assign pairs of testers
the same resolutions to test. This will provide for verification. I will
volunteer for LBR or x3 testing. Also, I suggest you pick filters that will
give the same results when repeating a test. This will help to establish
a Baseline. Later other filters (i.e. Blockbuster noise) can be added to
your testing. :)

-black prince

Re: GOP
 

So it seems the lower the resolution, the tighter the GOP :idea:
Did you try other different settings, with the MAX frames per GOP set to 8, 9, 10, 11, 12, etc., to find the exact minimum file size spot?
I'll try some tests in a little while at 352x240.

-kwag

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

-kwag

I will volunteer as well if you need it. 8)

Re: GOP
 

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

At what resolution did you encode to get those results.

Hey go ahead and start testing black prince :D
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 8O . 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 :twisted: 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 :x CQ_VBR is a weird beast :roll:
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! :mrgreen:

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 :D
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 :idea: :?:

-kwag

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

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. :lol: 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? :wink:

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

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 :D . 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 ?

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

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 8O :).

Please don't introduce any more variables!! :lol:

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

-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