V, what feature will you first add when you complete the hack? What are your priorities?

Ok, in an effort to help answer some questions and hopefully keep the "what features...etc" questions down to a minimum, I'll state some generalities.

"hacks" are different than writing code. Hacks generally just change values of numbers or jump functions/features. Don't hold out too much hope of getting features/improvements that are not already part of the code.

This GH1/2 work are hacks because the code is not going to be re-written to add special functions that were not there to begin with. Adding things like that would be nigh impossible in assembler and especially so without guidance from some higher level code or documents.

That being said, I believe that since a lot of research has already been done on the GH1, that any improvements on the GH2 will start with similar improvements such as bitrates, language selection, region changes, etc.

Anything else after that would be up to VK to decided what changes are the lowest risk/highest reward or simply, what is easiest to do.

It then moves to testing. People will be asked to test the changes on as many cameras as possible. Just like the GH1, there might be problems at first so don't expect perfection on the first try.

Lets be patient though.

>Did the guys from ML had to code feature like Zebra Stripes from scratch, or is it easier to do that on Canon firmware

ML uses foundation made by CHDK. I think thaty some code came from here.
Also other part is that OS is known for years and plenty of debug information is present.

i hope for all of you guys that you are not holding back any production plans while waiting for the hack...
it could work, it might not, it might be great, and might be of a just little advantage.. (with respect to Vitaliy ;) )
from what i read here it could take a few good months, or even 1/2 a year (until finished & approved hack tests)..
so unless you find GH2 completely useless at the moment (not my case - i will use it for a feature),
there is no use waiting.

>I do not know where you got it, and that you assume under "approved hack tests" :-)

i just tried to gather any information from all the discussions (that is, here), and it looks to me that doing all
the tests with as many cameras as possible until the hack becomes 'stable' could take a few months, no?
correct me if i'm wrong :)

>tests with as many cameras as possible until the hack becomes 'stable' could take a few months, no?

You are citing words of @svart here, not mine. And add here speculation of your own.

Would it be possible to write to an entirely different codec at 50 mbps?Not that any of these details really bother me anyway. Is the mpeg data from the avchd(mts) the same as the data contained in the mxf container and would that container be a better solution for the gh2 at 50mbps and up?

All I need is for Vitaliy to write in a new Redspace R3D codec 5:1 raw. And 120 frames a second for that ultra slow mo. And to enable esata, So we caN plug in our own 1.8" SSDs.:-)

@disneytoy
-exactly!

>fs100 looks like the real winner this year for sure, I'm leaning towards the nano maybe the samurai, I think the ninja is not the answer for this cam.

Remember the samurai doen't have hdmi imput only SDI so it won't work with the fs100.

Hey Vitali, Do you have any possibility to make pe 24p mode with no "strobe" movements? to have something smoother...

@crackermd 1/25 shutter speed is the closest to 23.976 fps in GH2 at 1080p24 mode. Wouldn't it be enough? Although I sure hope multiples of 23.976 for shutter speed become available in FUTURE bodies. Also multiples of 60p.

e.g. 24p, 25, 30, 40, 48p, 50, 60p, 60 (fluorescent lighting), 72p, 80, 96p, 100, 120p, 120, 125, etc.

I thought higher frequency leads to more motion strobe.