I'm currently doing a classic anime and I play with the GOP length to see what is the best.

The results I have are VERY surprising !

All tests are done with 1-5823-2-1-XXX as GOP structure. Only XXX changes (no scene change detection). And there are the resulting file size of the encoded samples :

GOP25 = 2582 Kb
GOP15 = 2342 Kb
GOP10 = 2118 Kb
GOP05 = 2801 Kb

How can this be possible ? The lesser the GOP length, the smaller the file
(except with very short GOP5 where the file is much bigger)

Note: I am going to encode all the video (22 min long) in GOP15 and GOP10 and I'll tell you the results.

I'm sure that's where you'll see the difference

-kwag

Need one hour to see that

But can you explain why these strange results on the samples ? That's sound so weird to me.

Not necessary. The size depends on a context of GOPs, how many I,P and B-frames are there, and also how macroblocks are chosen during encoding - how many bits in them.

__________________
are you ready for year 2038?
x+2038-1970 > (2^31+1)/(365.25*24*3600)
/dev/mem < /dev/null

This is determined by the GOP structure and in this case, the structure is the same for all the encoding.

But with a shorter GOP I should have more I frames, so a file bigger, not smaller. I will analyse the I, B, P sequences toworrow to be fixed (it's 2.30 am here )

Okay, I just finished the encode of the whole movie.

AND THE WINNER IS ...

GOP15 = 132 922 Kb
GOP10 = 122 231 Kb

You do read correctly : the shorter GOP gives a file size 8% smaller !

I let you think about this, I'm going to bed now

Hi Phil,

I'm pretty sure you used the same CQ for all tests, right
TMPEG will allocate bits differently.
So the real test would be to calculate the correct CQ for your target, and then encode.
You MUST do prediction with every different GOP size
You'll see that you'll obtain the best quality with your final encode with the GOP of 24 or 25

-kwag

Not yet asleep

To be accurate, I used the same CQ_VBR as I encode in 352*288.

(note: I do an anime, so here I limit the GOP to 15)

How can it be ?

1/ the sample file size is bigger with GOP 15 than with GOP 10 so during the first step of prediction, if I start from the same CQ_VBR, CQMatic will jump to a smaller value with GOP 15 than with GOP 10. And in the end, the optimal CQ_VBR will be at the advantage of GOP10. That's mathematical.

2/ the shorter the GOP, the more I-frame I have. And a perfect video is when you have 100 % of I-frame, right ? So with a GOP of 10, the quality should be better than with the GOP 15.

According to that two points : how can it be possible to have a better quality with GOP15 than with GOP10 ???

Do you suggest that visualy the result will appear better ? That's become weirder and weirder...

BTW, I finished a complete cycle (prediction / encoding / muxing) with GOP10 and the CQ_VBR was 17.85. I will do with GOP15 tomorrow and tell you.

But can I suggest you to make a test of your own ? That is not logical at all to have this kind of results. That's the first time I use shorter GOP, so I never noticed that the generated file is smaller. I always assumed that it will be longer !

If other tests (on regular movie, not anime) confim that, we will have to re-think some concepts of KVCD.

Well I hope I did understand your Workaround well DialHot

In case of animes regulary you will get a very good I frame compression. Thats why more I frames won't result in that much more endsize.
I guess you're very in Photoshop and so do a Jpeg compression (save for WEB) on an anime picture and in comparison on a simple "reality" film picture. As I Frames got a compession similair to JPEG thats why you won't have that much bits on I frames. BUT the problem on animes are the P & B Frames as they still work predictious/bidirectional to the forwarded/afterwarded Frames and thats why in case of animes sometimes the plain surfaces and so on get a little uneasy. But still we stand in here with that shorter Gop=less filesize phenomenom. I think as I frames by doing this will still give artifacts, these artifacts will be handled by the B & P Frames and in your case of YOUR special anime this results in a more complexitivity. (just a fast guess of mine but still "Freaky" as generally anime encodings behave)

And thats also why optimal anime matrixes do have a simple "bandpass" filtering.

Kika at doom9.de/Gleitz, the author of his optimated anime matrix recommends these values:

But this is a matrix not for compression purposes .... posted only for understanding the special anmie-case when doing mpeg encodings.

This explanation sounds correct.

I'm not sure this behaviour is tied to the anime a currently doing (that is, btw, a bad VHS capture) but what you tell about particularity of matrix for anime is surely the correct way to understand what happens here.
In fact I must confess that I do not understand a lot of things in matrix so I will take that for THE explanation and stop to ask myself questions

BTW, I finished the encoding and the results are :

GOP10 : Cqmatic found CQ_VBR 17.85 / file size 123 281 Kb (ie 120 Mb : that exact size I asked to have

GOP15 : Cqmatic found CQ_VBR 16.31 / file size 122 174 Kb (ie 119 Mb)

But, the weirdness isn't over : I compare both video side by side with a StackHorizontal command and... the GOP 15 is far better

I wish I never have started to encode these animes. I have 75 of them to do. I will never finish

Never stop asking yourself questions ... that have never been your way

In case of a VHS Capture where where there aren't highfrequencies anymore you could try two methods:

1st Try:
Give that DCTfilter a blast by cutting the high frequencies on last three values (1,1,1,1,1,.5,.25,0) as first of all you won't see it on TV and second as its already lowed away by heavy avisynth handling on VHS Sources. (Everything based on that I hope that I understood the purpose of DCT Filter Well ... if it bases on the DCT 8x8 Matrix logic! and that should be)

Because the last two collums can be cut heavely! On 625 Line Based PAL TV sets (as NTSC also is line based this logic will be the same)

Watch CCE and you will recognise two modified standard matrixes.
Very Low Bitrate and Ultra Low Bitrate.
There you can clearly see what will be done at the last collums down to the bottom... full of 99, 99, 99, 99 etc. that means "CUT"!

And thats also what does DCTFilter as the values stand for the collums and their fills.

2nd Try:

Use this "cutting" on the KVCD matrix cause there you can exactly modify the Cuts based on the frequencies AND for shure based on that ZigZag Scan, cause this to mee seems as its not supported by DCTfilter.

So, if you process already low frequency sources like denoised VHS Captures, this "Could" be your choice:

And maybe you could use as nonIntraValues (in case of anime) just Kika's - bandpass values I posted above, so you have to try (As I got now anime right now here).

I will give that a try but do you have an idea why the longer GOP with a CQ_VBR far lower than the one for GOP 10 give a better visual result ?

Before to compare I ws sure that with CQ_VBR=17.85 for the GOP10 and 16.31 for the GOP15, the second one will be awfull. That's sounded logical.

Exactly
And if you try a shorter GOP ( <10), even though you'll get a higher CQ ( or CQ_VBR), the higher GOP in comparison will look better.
Up to a point, of course, when the GOP starts to get too big, and you start getting the "ghosting" effect.
So for Animes, your "15" sounds like optimal for that movie.
Lower GOP values, even with higher CQ_VBR results, will look worse because of B and P frame shortage.

-kwag

Yes, I do
A CQ(CQ_VBR) value is only a reference, internal to the encoder. So actually the smaller value will be a higher quality with a higher GOP.
Did you drag your .M1V files into bitrate viewer
Take a look, and verify that the one with a GOP of 15 has a LOWER Q value than the one with the GOP of 10

-kwag

Okay, I understand. The same way we can't compare a CQ used for two different movie.

GOP15 has average Q of 3.86, GOP10 is 4.10. You're guessed right