You know, that makes a lot of sense. For very noisy sources, it might be best to reduce the number of P- and B-frames, since as you say it's possible that describing the differences might require a higher bitrate than simply using more I-frames...

I think most of our questions regarding the GOP could be answered with a sophisticated MPEG analyzer. Anyone know of such a beast?

You´re absolutely right! with I=1 we´ve got GOP= 1+p+(P+1)*B (-B if Closed GOP selected).
But my question remains: Why P=max GOP? and why 15 (just on example)? If I count correctly, the GOP is cutted between a 2nd and a 3th B frame (not the best place to stop)

Well this could also be true for DVD encodes using CQ_VBR at 11. The resulting Mpegs are going to be noisy so Tmpeg could be finding it harder to allocate a bitrate

Jim

It's just a NUMBER , OK?!!!!
U can use any number , ANY number ! (like 5823 - signature of KWAG) :D
It can be big any size but not less than optimal value - THE ONE our Bright minds are serching for 8) :?
Size of GOP depends on MAX frame numbers in gop . This number is responsible on GOP size .

bman

Maybe we're using a different definition of "noise". I'm referring to random variations (i.e. additive white noise) in the source material that confuses the MPEG encoder and causes unnecessary allocation of bits that could be better spent describing actual details.

A low CQ_VBR doesn't make more of this kind of noise. It might make "mosquito noise", but it's not really noise at all. We should probably start calling it the Gibbs Effect instead :).

8O wow, kwag and others... now this is getting really odd...
So as I understand ya'll correctly :) ...
There's an optimal GOP for each resolution + for each CQ_VBR value of this resolution ?
Let's just go ahead and test... I'll run a couple of tests on the PAL templates, of the KVCDx3...

later guys...

Well, I should also have told that the max number of frames in a GOP is the same as the number of P-frames..

so what I really meant was that this thing we are contemplating could really turn out to be a tough case. In my tests GOP size 36 frames produced a slightly smaller file than a 30-frame GOP. Then again, I got the smallest filesize with a max 8-frame GOP..confusing!

I just hope that this value would only depend mostly on the resolution.

I think I know what we have to do. If for a given CQ_VBR there is an optimal number of max frames, we need to calculate a formula that applies either a negative or positive offset to a pre-determined center point of max frames. This way, when we change the CQ_VBR value, the max frames is adjusted. Of course with a minimum value and maximum values. Like MIN_P=6, MAX_P=36.

-kwag

Not really -- the number of frames in a GOP is the sum of all I-frames, P-frames and B-frames. Thus the number of P-frames in the GOP should always be less than the total frames in the GOP.

I think enough testing will make things clearer...

I think it's time for SansGrip to start planning another util..THE P-REDICTOR!

Jesus, we'll need more time predicting the GOP size and the CQ_VBR value than encoding the movies :lol:

Can you give an example of how this would work?

(And by "P's" you mean "pictures", not "P-frames", right? :?)

Opps, sorry SansGrip, I had edited the post, but you beat me to it on the quote :D I meant max number of frames. Not P's.

-kwag

heheheh actually I was just imagining how this could be incorporated into KVCDP... :D

If you think this is complicated check out the process used to transfer a studio release onto DVD... Those compressionists do all this and more -- usually on a scene-by-scene basis! 8O

Some more clearing :wink: .. I meant that I used the same formula as the other people here, 1-8-3-1-8 produced the smallest filesize :)

ARGH!! WE'RE ALL POSTING AT THE SAME TIME!!!! :lol: :mrgreen:

We go on like this, this thread will have 20 pages by the end of the day :lol:
At this speed, we'll probably have a solution to all of this in a matter of hours :mrgreen:

-kwag

I would as well if they paid me big money too :wink:

To be honest, if this thing gets included in the KVCD Predictor, it's going to be the sliced bread of amateur(?) video encoding, if you see what I mean 8)

Distributed computing's the name of the game these days..the interest in this has been huge, I must admit.

hehe no kidding.

Right now I have a picture in my head forming...

It involves selecting several sample strips (say, "this represents the average amount of action in the film", "this represents more sedate scenes", "this represents particularly high-action scenes", or whatever) and encoding them, then running them through an MPEG analyzer to determine how efficiently each strip is using the CQ_VBR and GOP settings, then generate a new template (incorporating "force picture type" settings) to use based on the analysis, then repeat...

Sort of like a feedback loop, all in one program...

8O

Another thought...
 

wrt the analysis idea, if one were to go through the encoded sample strip and calculate the average size of I-frames, P-frames and B-frames, shouldn't it be possible to calculate the best GOP structure from that information?

In other words, let's say we had the following results from the analysis (numbers are made up and probably bear no resemblance to real figures):

Avg. I-frame = 25kb
Avg. P-frame = 10kb
Avg. B-frame = 5kb

This information would suggest a large GOP, with as many P- and B- frames as possible.

The question is, what would the average sizes be for a movie that compresses better with a smaller GOP? Could it possibly look like this:

Avg. I-frame = 20kb
Avg. P-frame = 22kb
Avg. B-frame = 25kb

:?:

What else would account for the phenomenon?

[quote="SansGrip"]Judging by my copies of Highlander and 'Blackadder' these so called compressionists can't come up with anything better than a standard KVCD LBR!

This is starting to get hairy now 8O , like the case of the chicken and the egg. Which came first :?: The CQ_VBR or the GOP size :?:

-kwag

Sounds to me more like a software "Phase Locked Loop" algo :idea:

-kwag

I think we make a sample strip and determine a good CQ_VBR the standard way. Then perhaps do an analysis of the MPEG as suggested above to determine the best GOP structure, then adjust CQ_VBR accordingly. Hopefully a small-ish change in CQ_VBR to match desired target size won't change the optimal GOP structure...

Ah, but then you get something like LOTR... :)

... Because if the changes are to great, we fall into a "positive feedback" type situation where a change in CQ_VBR throws off the GOP, and then it's like a never ending loop. And that's going to be a pain 8O

-kwag

Or how about this: We figure out manually how big a change, on average, we get from optimizing the GOP for a given CQ_VBR. Then we deliberately miss the target with our file size prediction by that amount, then adjust the GOP...

Thinking Thinking ....... Thinking ..... :lol:

-kwag

Got something :!:
This is what I'm doing manually, and it seems to work correctly.
Start your encode with regular file size prediction. Say at CQ_VBR=25 and a GOP of 1-18-3-1-18. ( Half way between 1-36-3-1-36 )
Keep encoding as usual to target your wanted predicted file size. Then after you're done, go into TMPEG and select a 5 second range. Take something in the beginning of your 100 second window. We still haven't removed the file prediction script, so your range will be within 100 seconds. Now encode this 5 second clip. Take a look at file size. Now change your GOP and encode again. See if file size is larger or smaller, and adjust GOP up or down a couple of MAX P's accordingly.
The 5 second sample clip is very fast to encode, so you can play up and down pretty fast until you find the optimal max number of frames. Now after you're done, remove the frame range in TMPEG and go back to regular file prediction once more. After one or two runs, you should have your target again, with a slightly higher CQ_VBR value, but not that high to make a difference for a new GOP calculation. Hopefully this is what needs to be automated :wink:

Edit: I'm doing this right now, as I want to compare the original predicted file size with bit rate viewer, and then the new optimized mpeg. Because both file sizes will be about the same, I want to examine both mpegs to determine if the optimized mpeg has a lower Q factor meaning higher quality. Maybe not visually, but mathematically. If this is true, then we have achieved a GOP optimizing method. If the quality is the same, then CQ_VBR is playing a trick on us, and what we're doing is not worth it.

-kwag

I'm also encoding The Cannonball Run for the second time. The first one had 8 frames/GOP and this one 15. The first one is a couple of megabytes short of a full CD, let's hope that this other one is as well. Then I could check the files both visually and with Bitrate Viewer. Hopefully this will provide some extra information.

And what comes to bad compressionists, nothing can beat Future Film's remasters of Time Bandits and Monty Python's Life of Brian.. they both look more like a really bad XVCD than a DVD to me. The only good thing about them is that they were cheap.

LOTR
 

Sansgrip

On the LOTR subject. I just watched the region 4 PAL Special Edition which has the movie on two discs.
It looks as if it needs a bit of blockbuster to me.!!!
For 2 discs it should look WAAAY better.

Re: LOTR
 

Beauty and the Beast looked a bit dodgy in places! - and that cost me a fortune!

What makes me laugh is these people have over 8 gigs to play with.

Let me know if it works, and I'll try duplicating here. If it works for me too I'll start figuring out how to add it to KVCDP :).

Re: LOTR
 

I can only speak of the region 1 "normal edition" of it, full-screen at that (my wife picked it up and forgot to check which version it was, grr ;)).

I've not looked very closely at it, but from my regular viewings with family etc. it looks pretty darn good.

Re: LOTR
 

It's because they try to jam so many BS "extras" on there too. If they used the whole 8gb for video (aka SuperBit discs) the quality should be superb. Usually is, sometimes isn't.

What gets me is that I don't believe I've ever watched one of those "extras" more than once. Most of the discs I've bought, I've not even watched them at all. Very annoying.

Quick... quick!! :mrgreen:

And the veredict is......... NOT WORTH IT. :evil:
The tighter the GOP, the more visible artifacts on low bit rates. So the higher GOP shines on smoothing artifacts. So the 1-36-3-1-36 is good enough to provide descent quality vs. file size. The smaller file sizes with different GOPs drop the overall quality too. I noticed it on a specific scene on "Red Planet" and after playing it over and over, I finally see that the longer GOP helps A LOT. So CQ_VBR is playing tricks on us as we change the GOP size. One more thing that should be tried is to find how long can we go in the GOP before we loose quality. In the original KVCD templates, this size was 48, and it caused problems with some DVD players. The "flashing" effect. With a GOP size of 36, I don't see anyone complaining. Could we jack this up more? How much more? Or is 36 good enough for what we are getting now?

-kwag

Booooo! ;)

My biggest concern is, of course, retaining compatibility with as many standalones as possible. Anything over 18 (for NTSC) is non-standard and might cause problems.

:mrgreen: :P

For DVD, yes 18 is definitively a must. For VCD playback, some will take long GOPs and others won't. Maybe 36 is good enough, or maybe there's not that much diffence between 18 and 36 and we can drop back to 18 for more compatibility :?: I'll make a couple of tests at 18 and 36. If there's not that much difference, I'll fall back the templates to 18 with a note that if your player supports longer GOP, then crank it up at your own risk :wink:

-kwag

352x480 cq 20 the movie was 112 minutes in length

-Christopher