Wow - really happy you're at least looking into this Vitaly! One of my main complaints about the GH2 is the lack of a 1080p30 mode with sound. I always record sound separately when it matters, but when shooting in 1080p24 80% (I convert it to 29.97fps when transcoding), slating every shot and not having waveforms to sync to is a bit of a pain.

Thanks again for your awesome work on this project - I've already used the bitrate hacks to shoot scenes for projection in a friend's opera - and they look beautiful.

also, i don't know what the problems are with the sound, but even if it was at the wrong speed or sampling rate, etc --- as long as that was predictable --- it would at least offer another way to sync 2nd system sound after a bit of time-streatching or resampling and would be more useful than silence :)

Very exciting. Using the true frame rate makes perfect sense for correct audio playback. Do you think this audio discovery will have a connection to enabling audio through the HDMI?

I found a terrible issue while testing the 1080i50:
With just 32mbit checked i recorded a 2 hours and 20 minutes video, a shot with no movements, quite poor in details amount and with slow variable light that comes from outside.

After few minutes (apparently same light) strong macro blocking appears in the mid-shadows and they stop after other few minutes. Then it appears again after few minutes and disappears after others.
The video is splitted by the cam in three files: the first contains 59 minutes, the second 1.11 hours and the third 12.28 minutes.
The gop structure in streamparser is perfectly regular even in the footage where i can see macroblocking.
The average bitrate is 10mbit, very low because i'm using a 2.8 80mm and the scene is poor in details with no movements.
The first image is a snapshot of the correct image, the second one is the image with macroblocking (not much evident because the effect is visible with movement).
The effect is terrible and pervasive.

@sdbest huh - I'll test some long videos myself as that is really important to me. Don't see how the macroblocking could have been a USB problem. I'm pretty sure that if the USB messes up during a data transfer it doesn't usually 'degrade' your video or data or whatever in any "logical" way (logical to a human, that is) - the data transfer is rather totally stopped and unusable. There is no "bad connection" like in analog - it's either connected or it ain't :) The unreadable clips - now THAT could have been a USB problem. I'm just in the throes of developing a USB MIDI device at work, so I've become somewhat familiar with USB lately.

@Elenion I can see that the 2nd frame is compressed worse. What's weird about them is the 2nd frame looks interlaced (1/2 verical resolution) while the 1st looks progressive - was your shutter speed on auto and changing so that sometimes the fields were from different exposures, sometimes not? (i actually forget if you go above 1/50 sec on the GH2 when shooting 50i - ?) Or maybe there were vibrations in the room due to some appliance or pump or activity outside going on and off randomly and if the GH2 on the tripod was vibrating, the picture could be moving slightly, making the interlaced frames different from each other, rather than exactly contiguous as they would be in complete stillness, and therefore making compression less efficient. Just a silly hypothesis and probably not at all reasonable.

Beautiful work !
Many thanks, Vitaly, I will soon donate when I'm back.

While testing and all features seem to be working,
I spent a little more time on compatibility issues.

1280x720x50p, I chose 27,5Mbps to have something SONY DVD-A compatible and 35Mbps bitrate to have something Blu-ray muxable. Audio bitrate set to 256kbps.
Previously after indexing and demuxing with DGAVCIndexDI 2038 I was able to use the GH2 streams directly in DVD-Architect 5.2 without transcoding. Now after applying 3.61d both elementary streams are scheduled for transcoding in DVD-A 5.2.

I used DG VBV Checker 1.8 on the new video stream and found a wrong entry:

bit_rate_value_minus1[0] = -28904 [4265370624 bits/s]
cpb_size_value_minus1[0] = 25650 [26266624 bits]
cbr_flag[0] = 0

Previous setting read from stream:
bit_rate_value_minus1[0] = 15659 [16035840 bits/s]
cpb_size_value_minus1[0] = 10961 [11225088 bits]
cbr_flag[0] = 0

Looks as if the patch breaks at least the value
bit_rate_value_minus1[0]

Maybe only the minus sign ?

Futhermore the coded picture buffer size seems to have changed with the bitrate setting.
Overflows / underflows may occur now. Comparing previous/new bitrate patterns seems to give the impression that more values have to be tweaked to have a valid stream.
Max/min bitrates are not respected anymore by the encoder, the more user min/max.bitrate are set apart, the more over/undershoot is to be seen.
I guess a buffer setting has to be tweaked, but no time now to dig deeper..

Even the 256kbps AC-3 audio is no longer accepted for muxing without transcoding.

@sdbest
@arvidtp
Shutter speed at 50, no vibrations, no usb cable (taken directly from the sd as usual). The frames around the second i posted looks the same (with different kind of macroblocking), the bitrate is the same of the good ones.
My opinion is that the encoder, with a still scene, degenerates with time, accumulating progressively some errors until it refresh. Vitalyi, what do you think?

@APXmusic: absolutely agree with you! Even I opened a similar topic about such a matter.
The most of the users here are deeply lost in conquesting the best and highest possible bitrate, I think. But this utopian aim will give nothing at the end, be sure!
It seems like the most of the users here have spent their money not to shoot and create something valuable, but just to play with bitrate hacks. 4K?!? Hehehe, and why?...
The settings! The settings are the most important matter that needs to be worked on in the firmware!!! And it's a big pity that in comparison with Canon hackers, our general PTool hacker is very far from this purpose... Nothing personal, otherwise respecting his huge work anyway...

Hi, sorry for my english...
I've install the @kae settings ( seta.zip ), but when I start recording, the first and secondly second are 'broken' ... Have You a solution for this problem ? :)
Thx for your answers..

@RSW:

This is normal, we can´t change it. Try lower bitrates below 30 Mbit and the "blips" are history.

I have created an Excel file with all the settings that have been published these last weeks in the different forums. I only kept the settings provided in the form of ini files. The Excel file contains also, embedded, the ini files themselves so that everything is self contained.
Tell me if this is of any use to you and I will regularly update it.
In order for a settings file to be as self contained as possible I suggest that before posting to prepare a new version of the file only changing its comment field summarizing what works and what doesn't, the film modes tested etc...

Finally an issue that has not been raised before (maybe because it is a non issue) : does the firmware GH2__V10 that is used to hack the GH2 in anyway modify the ability of the GH2 to accept third party batteries? And can a third party battery somehow influence the reported contradictory results of the tests?

@pwc
Good initiative! It hepls when doing your own tests. Your recommendation to include info around tests and result in the comments is essential.

Ok, so ... it's normal .. ok but .. it's possible to not recording this first second in SDHC Card and allow only "FAKE" first second ? :) ( black screen for exemple ... ) ?