@cbrandin Thank you for the concrete and detailed explanation.

"This is what happened in the examples you posted where the min QP is 9 and the max is 35."

I was afflicted by this phenomenon all the time. "Whether this is good or bad," I could not be determined... Many thanks to the clear understanding that you do. Use the proper frame size and Q, and I think let's make the correct patch. Thanks again. :-)

BTW, I always use the Stray's chart has been introduced by qwerty123.

@qwerty123

Thanks - that's the one...

@cbrandin I didn't produce the chart, but I posted them in the first post of this thread: http://personal-view.com/talks/discussion/2017/importance-of-proper-tests-for-reliable-in-cam-playback-lessons-from-the-field#Item_39

The AQ setting really only works correctly with normal GOP settings. With short GOP you have to set Q manually to get the right results.

There are four settings that need to be balanced: Q, Frame Limit, Video Bitrate, and GOP.

Q and Frame Limit are set depending on how you set Video Bitrate and GOP. If you compare GOP configurations you have to consider that low GOP settings need to have higher Video Bitrates to support the same Q value. For example:

The default Q value is 20 for 1080p at 22M at GOP12. To support the same Q value with GOP6, you need about 40M, with GOP3 you need around 80M, with GOP1 you need about 190M. That means that if you are running GOP3 at 143M, you would need to set Q to around 15-16. If you were using GOP1, you would actually need to set Q to about 22-23. Or, put another way, GOP6 requires approximately 1.8x the bandwidth of GOP12, GOP 3 approximately 3.6x, and GOP1 approximately 8.6x.

The default Frame Limit is 7864320. The highest frame limit that actually does anything is about 10000000. You can't raise Frame Limit unless the Q has been properly reduced, and you must lower it if Q has been set to over 20. In the above GOP3 example you could raise it to 10000000. In the case of GOP1 at 143M you would have to lower the Frame Limit to 5958333. The GOP1 calculation is simple - take the Video Bitrate and divide it by # frames per second: 143/24=5958333. There is another parameter that affects all this - xxxx Top Setting (xxx is the mode you are setting). Your actual Video Bitrate is the lower of the Video Bitrate setting or the Top setting*1000. If you haven't checked the Top setting you can just use the Video Bitrate setting.

These settings only have the desired effect if they are within the bounds of what the codec can handle. Bad things happen when these are not calculated correctly. For example, if you set Q too low you end up with frames that have some macroblocks coded at the desired Q value, but because the codec runs out of bandwidth it will encode other macroblocks at a much higher value in order to avoid crashing - or, some macroblocks, or even entire frames will be skipped. This is what happened in the examples you posted where the min QP is 9 and the max is 35. This should not happen, especially with a chart. If the difference between min and max values is more than around 2 with charts then you have a problem. The same kind of thing can happen if you set Frame Limit too high - but in that case it will be the P and B frames that fail most often, or the codec will crash altogether.

Basically, you want to set these parameters so that test charts result in well behaved streams. With the "Room" clips you would expect bitrates to drop, or QP to come out lower. That's how VBR codecs work - when there is less detail the bitrate goes down. Having the codec work right with low detail scenes only is meaningless.

Chris

@bkmcwd Hmm... an intersting comparison, but I find the encoder begins to settle more 5 secs in, could you upload some Q analysis at least 10 seconds into the recording? Many thanks for these results.

@driftwood Thanks for always helping me, mate. :-)

"You need a balance of resolution and good Q."

What kind of thing is this concretely?

I am confused. :-(

Since I think that you can also understand my strange English, I ask you. It is recommended by you and I came to look at macroblocks. Although I understood that low qp produced high definition, if I try to use low qp like the upper sample, high qp will be mixed because of the limit of frame size. On the other hand, although there is no extremely low qp when it sets to a certain value of low qp, high qp also stops mixing, like the upper sample. Although I do not understand controlling qp how for whether it is best, I think that big frame size is required to lower the average value of the whole screen at least. Naturally qp low on the average enlarges frame size.

Many of my friends think that higher resolving can be obtained with big frame size. Although I can understand their idea, I cannot do proving it well.

If high definition can be obtained regardless of the size of frame size, I think that all the GH2 users SHOULD use your patch silently. It is because I understand well that your patch is rational and wonderful.

For example, if there is a conclusion "AQ4 is high definition under the Lowlight, and resolving becomes low from AQ2 under the usual brightness", I would like to know it. If there is such a conclusion, as for 3GOP which can realize big frame size so that my friends may think, coexisting with rational Intra has a meaning.

Thanks for your advice!

@cbrandin Thanks for your great work. :-)

I have a question to you. These are the results of shooting with the tea garden using my Q13, AQ4, and Q18 all 3GOP patches. The first screen shot is a result in each Streamparser. The second is a result of StreamEye. The third is the result of my investigating 40 macroblocks from 40x20 to 43x29 of the screen of Streameye.

Is an image quality of which the highest among these three patches results?

Although I thought that AQ4 was always high definition, in about 800k small frame size, qp will become high on the average because of extremely low qp. Then, I thought that the patch of the big frame size set to qp low rather on the average became high definition more. How do you think?

The same test on a faster lens - f2 Olly or voigt 0.95, requiring a much lower ISO (160) at 10iq/10q shows zero quant lines at all - ie everything is Q'd nicely (which suggest AQ4 can be used fine with decent lenses/lower ISO). This suggests once again that low iso or fast lens combination is imperative for the GH2. I am also unimpressed with the Panny lenses which come with camera. Bring on some decent fast lenses from them.

Here is a visual test showing hi bitrate INTRA 1080p with settings iQ=10, Q=10 with AQ switched off (Test1, see left pane view) versus the AQ4 setting with GH2's default IQ=20, Q=20 (Test2, see right hand pane). Notice the lined quantisation difference with the manual setting (barely any) against the AQ4 'very lined' (alternating lines mean light lines better Q and dark lines worse Q). The first graphic is the picture view at frame 0 on both streams. The second graphic is a visual of the Quantisers both streams at frame 45. The third graphic is a mb sizes view showing macroblocking at frame 1 on both streams. The test was conducted from a moving recording on a motorised tripod. The noise is due to 1600ISO, 50 shutter in a lit room, on a 14-140 panny lens (set at 18mm).

Findings: Notice how by setting it to 10 & 10 in the manual recording the actual IQ and Q now = 16!!! The lower IQ & Q has also given a more defined image in resolution, see the woman's back, however, AQ4 blurs these more if you look hard. The AQ4 on this hi bitrate gives a alternating low/high lined quantisation, whereas the manual IQ/Q doesnt so much.

The frame min QP and Max QP average out as follows. Setting IQ=10,Q=10 produced an avg 'frame Qp' of between 8min and 15max Setting it to AQ4 only produced an avg 'frame QP' of between 2min and 18max However, the avg macroblock Qp was almost constant 12 for the IQ/Q=10 setting and, the avg macroblock Qp for the AQ4 test was alternating line by line from 10 to 15 - very weird.

Discuss.

@driftwood

Sure, this is after all a public forum.

StreamEye does correctly identify that there are no 8x8 blocks in the video data, it's just the showing of the tables in the headers that is problematic - and that may not be their bug. For example, the stream may report that the tables are there, not provide them and not use them - I don't know, I haven't looked that deep into it.

There are a couple of other things Elecard might consider adding. StreamEyE doesn't provide "MTS" files as a compatible option, to load the files you have to select "All" file types. Also, the tips (pop-ups) feature is quirky, you have to select the display window by clicking on the title bar to make them work, clicking inside the window doesn't seem to work.

By the way, have you noticed their "Slim" version of StreamEyE for $50? I doesn't have all the features of regular StreamEye, but I have found it very useful nevertheless - and the price is right.

Chris

Here's the active picture parameter set for an I frame as reported by CodecVisa - the 8x8 matrix flag is 0 (no 8x8 matrices):

The H.264 standard also describes Arbitrary Slice Ordering (ASO), Flexible Macroblock Ordering (FMO), Scalable Video Coding (SVC), etc, etc... none of which is used in the GH2. I think you're really confusing the issue here.

Chris