did not do deital test till I'm sure its stable. Spanning test: stapes after ascend file

And this is how it should look, but still not so enjoyable. iso 3200

screen

@humpman many thanks for the careful tests!!!

first things to say:

The images from @konjow using ipx8 in good light low iso looks pretty good, but the 3200 iso image you did using the ipx8 shows mud in the center of the image and jagged lines. I believe this is a result from the lower datarate in ipx8. Compared to your patch, ipx8 shows 27Mbps, your patch shows 43Mbps, large difference!

But your patch shows frames size larger than the constant values and maybe this can make your patch unstable. The maximum frame size in your patch shows 985728 for P frame and 790272 for I frame which are larger than the constant for 1080p which is 777600.

If we consider the constant for 1080p value as the maximum frame size for camera stability, so the ipx8 is sited below it, a desirable result, the maximum I frame size is 690816, less than the constant which is 777600. My math calculations when developing the ipx8 was to achieve this, frames size under the constant values.

The iso 3200 image from your patch looks good, to my eyes there is no way to be much better than this, because the noise and horizontal pattern from the sensor is heavy, very heavy in 3200 iso in the GH1, better we try to get a good iso 1600 image because it is usable. The still image is always better than the video image in same high iso.

I am happy to see you can record wrapped 25p for about one minute death chart using the ipx8, this is good stability. The death chart streamparser screenshot shows the I frames size peak around 8x the lowest P frames size, this is the idea I used to develop the ipx8.

I am curious to see a death chart streamparser screenshot from ipx8 recording in wrapped 24p to perceive if it can keep the frames size under the constant values because some reports say that the datarate in wrapped 24p is bigger than the wrapped 25p. There is 10% room for increase the datarate and keep frames size under constant values, so it seems 24p will work good also.

About good light and low light: the images from ipx8 in good light low iso looks pretty good. But for my eyes the 3200 iso from ipx8 is bad quality, so maybe the ipx8 will have a good performance up to iso 800, or iso 1600 with luck... the datarate in ipx8 is not enough for iso 3200.

Now the problems for solving this high iso issue:

First problem is: if we want datarate increase in ipx8 maybe the constant values will need increase, but adjusting the constant values for the GH1 is a mystery, there is no guarantee it will work good... needs tests...

Another problem is: if I increase the datarate in ipx8 and keep default constants, the maximum frame size will become bigger than the default constant value, and maybe this can make camera unstable...

But there is a hope:

there is a trick to lower the maximum frames size: to use a lower gop, a lower gop can share data among more I frames and maybe can allow a higher datarate without increasing the frames size so much... but this is a theory, needs tests...

here are four patches, variants from ipx8.

they are an attempt to increase the datarate and lower the gop to try to keep the frames size under the constant values for both 1080 and 720. lowering gop too much can make the I frames small and bad quality, so they needs tests in death chart and in low light iso 1600 to perceive the frames size, image quality and stability.

setf and setg are 40Mbps with overall 42 and video buffer 50

the setf is gop 10 - 8 - 8 - 7

the setg is gop 6 - 5 - 6 - 5

seth and seti are 43.5Mbps with overall 45.5 and video buffer 50

the seth is gop 10 - 8 - 8 - 7

the seti is gop 6 - 5 - 6 - 5

@humpman your garden is welcome! try it in these patches in iso 1600, I believe iso 3200 is too much for the GH1...

Default tables

@apefos mix2, first image wrong, can't delete

@humpman thanks for this test, the comparison between mix2 and highest_datarate is very elucidator, very clarifier.

The streamparser screenshots shows that the higher quantization for P frames is welcome to increase I frames size in low light. Also it shows that it is not good idea to have same matrix for I and P frames, P frames needs to be higher quantization in matrix as you already did. But the quantization in mix2 is too much high for P frames because in death chart the P frames are very small. Highest_datarate patch is working good in the death chart, but performs badly in low light. Mix2 is the opposite, performs good in low light but not so good in death chart.

Now the task is to find the amount of quantization to implement in P frames matrix to get the best of both worlds, good low light performance and not increase I frames so much to keep frames size under the constant values and get a high datarate at same time...

interesting to see it can hold large frames... so we can try both things, lower gop, longer gop.

at first moment I will try a shorter gop in an attempt to keep I frames under the constant value, these patches below are:

43.5Mbps overall 45.5 video buffer 50

gop 10 - 8 - 8 - 7

three matrix design: 1.5x , 1.55x and 1.25x The quantization for P frames matrix is different in each patch. This is an attempt to make I frames size bigger in low light but not increase it too much in the death chart

We are almost there... I think a few more tests and we will have the perfect patch for the GH1

please try in death chart and in garden low light iso 1600

the different quantization for P frames can make a difference to find the best stable patch, and best image quality in low light, so please try the three versions:

Here is the m1.25x version with different gop to test stability:

the quantization in P frames matrix is 1.25x higher than I frames matrix

setd = gop 6 - 5 - 6 - 5

sete = gop 12 - 10 - 10 - 8

setf = gop 15 - 13 - 15 - 13

setg = gop 10 - 9 - 8 - 7

seth = gop 10 - 9 - 12 - 10

seti = gop 10 - 8 - 8 - 7

setj = gop 15 - 13 - 30 - 26 (defaults)

third upload has all gop options

@apefos m1.25x setd

@humpman It seems the lower gop is hurting some frames, some P frames are very low size. I think it would be good idea to try the m1.25x and the 1.55x with the default gop, both setj. thanks

@humpman I saw the pictures where you show the noise border. I believe this issue happens due to some reasons:

1 - datarate not enough to keep the texture in all areas of the image and then the codec preserves the fine details and smooth the gross areas to save datarate.

2 - long gop makes P frames to be more compressed and then mud shows up

3 - matrix and qp are high quantization and mud happens

4 - the camera variable bitrate decrease datarate so much in low light automaticaly

When I was developing patches for GH2 I perceived this same thing. To completely avoid this, the only patch which get rid of all mud was 120Mbps gop1 intraframe with 5:1 compression ratio, this patch has a low quantization in the matrix and qp and preserve all details, it keeps high datarate even in low light. I thinkl it is not possible to develop this kind of patches for other cameras, just for the GH2

please @humpman give a try on the m1.25x setj and m1.55x setj, both patches with default gops. this will be important to see if they can improve low light and keep stable in death chart. thanks.