@ivan858 "i had the bitrate drop off at 88mbs as well, so i jacked up the bitrate. 132mbs handles the death chart fine, i stopped it at 20 seconds. 154mb overloads the codec at 8 seconds."
Hey, this is great, that death chart screen grab looks like a real breakthrough!!! Can you post you settings file? I really want to try it on a "drive of death" through this tree-lined highway I use to try and crash the codec.
Thanks for pointing me to this discussion. I had totally missed it. Now I understand, although the tech back and forth is dizzying. I must say I don't know if I buy into any of the higher GOP rally for my purposes. If you want to shoot 'motion' picture style with the GH2 (which is all i want to use this for) then the motion quality is the thing. The Gh2 at factory default captured static shots just fine for me, it's the motion that looked like crap. An intra codec is the grail for this cam for me, so 1 GOP would be great but we'll never have it. 2 doesn't work so 3 is the shortest and best compromise. 12 seems so counter-intuitive to accurate motion capture no matter how big the p and i frames are that I'll just wait it out until the next ptools release that let's us get stable lower gop. Has anyone posted a clip with HEAVY motion (in front of camera + moving camera) with new stable 3.62 settings?
@kae Tests: 132mbs for 4 minutes, i frame minimum @ 5.6. Max recording time unknown. Records at 1gig a minute. average bitrate: -9,675,946?? 132mbs for 20 seconds, i frame minimum @ 5.6. average bitrate: 137,487,984
142mbs for 20 seconds, i frame minimum at 6.06. Cuts out at 1 min and some change average bitrate: 147,855,188
154mbs for 8.3 seconds, i frame minimum 8.08. Cuts out at 8.3 seconds. average bitrate: 159,180,648
I attached the 132mbs settings. Good luck with the tree filming
That doesn't look healthy. Healthy B-frame size seems no more than 30% of I-frame size.
132Mbps case. The codec might have calculated 132/2 = 66Mbps per GOP unit. Since there is not enough bandwidth, fallback cuts it to 50%. Then 33Mbps per GOP unit. 33 * .3 = 10Mbps allocated to two B-frames in one GOP unit. That is average 5Mb per B-frame. The remaining bandwidth goes to I frames.
@stonebat i'm not sure how this is all working. why are large B frames bad? i know you posted a ton of info on this in the other thread, but its hard to follow. Also, is fallback why i have a negative bitrate in one of the tests?
Frankly I don't know crap about how GH2's codec works. I've been plugging numbers. That's all.
What I'm saying is that such high bandwidth percentage of B-frames tells... it's not a good idea to use low GOP from 3.62 PTool.
Just like everyone else, I'm waiting for the next PTool. If it has a fix, it would require only 88Mbps to achieve 7Mb I-frame and 2.1Mb B-frame with GOP3 and AQ4.
Ok. Will try your settings now. FWIW I don't understand the high low b frame thing at all. When I first came up with the 65Mb exteme settings people bitched that small b frames were bad. Now it looks like small b frames are good??? Why don't we just compromise at BIG I frames only, no b frames or p frames and we'll all be happy ;-)
The GOP3 settings from 3.61 produced very small Mb size B-frame. @cbrandin's AQ setting dramatically improved B-frame size. Based on my testing, AQ4 setting produced B-frame size about one third of I-frame.
I like the fatter B-frame. But if B-frame become TOO fat, it lowers Mb size of I-frame. That is what's happening with @ivan858's settings. If all I frames, 154 / 24 = 6.4Mb I-frame. I'm not a fan of GOP1. Never will.
We know the fix is coming. We hope. When it's fixed, I will probably choose GOP6 instead of GOP3. With vast improvement in B and P frames, it seems GOP3 is overkill. Also GOP6 will have bigger Mb size for I-frame. 88Mbps GOP6 AQ4 could produce 8Mb I-frame. Also a good match with 720p60 GOP6. But there is really no good setting for all cases. Some like GOP3. Some like 6. Some 12. Just pick what you want and know what you get. That's all :)
I've seen big I, B, and P frames and little ones. I've seen them all close to the same size and I've seen them divergent in size. The one thing I have never seen is one frame that has amazing image quality followed by several frames that don't. That is what we should see if size had anything to do with it. I believe there is still an underlying problem with the codec and the way it USES bitrate. I know Chris and others are trying to tackle that. Until they do I think we are just juggling bitrate without adding quality to the image (other than the obviously but slight improvement of using higher bitrates than stock).
Agreed. I think we're just chasing rainbows until the next ptools. I am sticking with the 3.61 65mb extreme 3 gop settings until then. They're bulletproof, at least for me, except for the 10 frame glitch.
@kae sorry about that. I did a 4minute test with the death chart with those settings to make sure it would work for you. I guess the death chart is now the not so friendly chart..I had my 132mbs 24gop 4aq x2 buffers crash twice today when they only record at 60mbs..I think its the card because I had write errors before the cam was even hacked. Transcend 10
No worries! Crashing is why we're here, right? The day the settings don't crash we can all get back to work:-) I used your settings at 96mbs and could do 5 1/2 minutes on the death chart but it stopped at the 4 gig point and wouldn't span. The footage looked really bad in stream parser. It was high bit rate at first then throttled down horribly as it flat lined. I think it's no joy until 3.63.
I'm assuming you're referring to an .ini file? If so, import it into ptools 3.61 (not 3.62) create firmware and load it in the cam flashing as per instructions on the forums.
@kae yes, I am sitting tight with 3.61 currently. when 3.62 came out, the universe exploded, and I'm perfectly content to sit back and watch while Mr. V and others put it back together again. In the story of H. Dumpty, I'm probably one of the horses.