Hi there, I uploaded a 133 Mbit sample to Vimeo: You can download the source file there, it's 18 Seconds I beleive - this was simply the clip with the highest bitrate I shot today, but I shot several clips with bitrate around 120 with lenghts over 1 minute. Recording broke down only one time, without any apparent reason (scene wasn't more complex, resulting 2-sec-file has 115 Mbit) - and the card I used is about the cheapest class10 card around (Transcend) - so as far as I can say, these 120 Mbit settings are STABLE :D
I was wondering where CBrandin was. He certainly was the most valuable contributer last year (outside of Vitaliy of course). I'm glad to know he hasn't gone anywhere.
@fatpig not suspicious, he's been testing the hacks since the early days of gh13. i think he probably disabled the comments after inappropriate comments about his daughter on previous clips.
anybody would like to try my old 400 24 settings that i use on the gf1, i get 100 mbits stable on class 10 and still use it nowadays with no problems. all Q settings: set to 400 all T settings: set to 24 i dont have a gh2, but should be a good starting point
here is some more info on the 400 24 shot on a GF1
Nah.....I don't think so. He's a respected Vimeo poster and seems to have been with the GH-x series since day one. Let's just wait to see what he has to say.
I invested significant time and effort to look at the AVCHD encoder last days.
As result, PTool v3.61D will be coming soon. It'll include tuning of so called "internal encoder mode" introduced in GH2 (for example, 1080p24 has its own mode code that is calculated inside encoder). And many parameters tuning will be added also.
P.S. I'll be cleaning this topic leaving only really useful posts. No hard feelings, ok? Just to make it more readable.
I only tested that the 2 last digits in hexadecimal concerns the sensivity: 00 is the most sensitive setting, FF, the least. I didn't get to disable AGC in my various tests of different values on the two precedent digits. According to Vitaliy, the digits 1 and 2 after the "X" value concern one thing, the two last another thing (if I understood well).
Today I got an error message about NTSC/PAL problem. I have a PAL GH2 which I switched to NTSC(sometimes it seems I´m the only one here who wants 720p60 for fluid playback on monitors...). I filmed some scenes with 720p60, then suddenly I got an error about incompability of camera and card due to PAL/NTSC settings. After switching the camera on and off the problem was gone. Anybody else had this problem? For me it would be no problem to have a "fixed" PAL to NTSC conversion like in the earlier versions of PTool because I don´t need PAL framerate, really. Maybe the switching in the menu can cause sometimes troubles.
Btw, I changed progressive patch including bunch of internal encoder settings under the hood. During limited testing it looked pretty ok, no hangs. But either sensor mode is actually 60i or picture is processed before encoder or we don't understand something yet. So, we have same garbage in the bottom half.
Thank you Vitaliy. It is critical that the hack go deeper to have any further progress (24p bitrate the goal). Considering you're going into the quantization, perhaps we might one day do 10bit! ;)
This weekend I used the GH2 hack (720p 28mbps) for the first time on a film. One odd little thing I noticed was that the nle (cs5.5) was doubling frames randomly toward the beginning of the 720p file. It was very weird behavior... I assume the hack affects i/p/b frame type tagging or something along those lines. (it gets in sync after the first few seconds) So for the time being, I'll be recording a few seconds before the take begins. I don't know if anyone noticed anything similar? Anyway, here's a preview of the film, the hacked 720p starts it off: