GH1 firmware research volunteers required

Whats the advantage of MJPEG over AVCHD?

With MJPEG each frame is a JPEG image. With AVCHD only key frames are carrying full frame information. These are then followed by frames that carry the changes.
In fast moving situations the CODEC or its implementation is not good enough to catch and encode those frame to frame changes, resulting in "mud".
This is a simplified version, but should answer your question.
Live HDMI output it's very important our destination, ;-) it change the game! :bath:
'Live TV out' in record time too important thing (for steadycam operator) ;-)


and for more complicated production situations - for client's monitor support for example, for cranes, crashcams, focuspullers and so on

will be great feature even in no perfect quality

but thanx tester13 anyway))
I'm ready to forget the AVCHD option if we could get functional MJPG.

I am not sure if I can say the same. I picked GH1 over 7D because it allows, in FHD and SH mode, me to shoot as long as SDHC card can hold. 720/24p at 100Mbps would be great! But it will have less than 2 minute limit. With the current patch, 720/30p at around 55Mbps is only for 3 minutes. It is great, but I am not sure if I want to give up AVCHD/24Mbps with unlimited length.
and for more complicated production situations - for client's monitor support for example, for cranes, crashcams, focuspullers and so on

will be great feature even in no perfect quality

but thanx tester13 anyway))

Plus the ability to use an external recorder like nanoflash, 4:2:2 I-frame only 280 Mbps!

This is fantastic work. You guys are awesome! Hope you can find the way to open up the HDMI live with as good quality as possible. It would solve all the problems for.
Wonder if the eventual Panasonic AF-100 will deliver images as good as a mature version of this mjpeg hack...?
I would expect that no matter how much progress can be made on the GH1, it's still a $600 camera body. The AF100 is 10x more expensive and should have better everything -- better dsp, better compression, better OLPF, and on and on.
Some of the recent post speak of file spanning as if it's a missing feature, but it works fine here on original firmware AVCHD. Well, almost fine, as there seems to be a tiny discontinuity at the join between two files, though that could be a function of the NLE's file handling. But maybe I'm misunderstanding what's been said.
I studied the first two posts in this thread, and the increased quality results for MJPEG mode look promising. However it's not clear to me how the camera makes use of the four MJPEG E1 - E4 Quality settings, the four MJPEG E1 - E4 Tables, and the two Bitrate Adjustment settings.

It would be helpful if someone could post a summary (either here or in the first two posts) of min, max and default values for these Quality and Table settings, and how to gauge the bitrate settings to accomodate increased Quality and Table settings.
48p would be pretty sweet for mjpeg. i know the sensor readout is 24p, but if it's capable of doing 48p, then that gives it the ability to do slow-mo and easily drop it into a 24p timeline no problem. that's how avatar was filmed at least.
Wow....assuming no correction, that is astounding

Wow....assuming no correction, that is astounding

Low light test MJPEG vs AVCHD
Quality settings (E1 to E4) - 352, 220, 200, 184
Table settings (E1 to E4) - 24, 24, 24, 24

with this settings top bitrate is up to 55Mbps.

This clip here is 16.7 Mbps



Assuming you didn't do an CC to these shots, that is just an astounding differance. HD for REAL...I might export these to blue-ray to see how they play on the plasma, wife is going to be really worried when she sees me watching someone play with a floodlight on the plasma...but, she is used to it by now..
Great to see that the mjpeg option is picking up steam. Will definitely be donating more if I see progress toward 720/24p and 1080/24p! Keep it up Tester13 and all the other testers, your doing great work for low-budget indie-filmmakers. Is there going to be a recording limit on the mjpeg or is that in the works of being hacked?

PS. Figuring out the audio limiter situation to have control of audio levels would be a MAJOR plus for run-and-gun regardless of quality. Not the priority right now of course, but I do hope it's still on the list!
As for 720/p24, most probably it won't happen. But who knows.
1080p24 is probable candidate.
But reality can be tough.

Current progress.

I can change 1920p24 sensor settings and make weird picture for AVCHD.
Problem is that it is very risky part, any error can lead to freezing during setup of liveview, and I won't be able to change firmware. We'll leave that for GF1.
Although it may have been said somewhere in the 193 pages of this forum, could you please clarify...

Why do think 720/24p Mjpeg will probably not be possible?

been busy lately. but I managed to make an update to wingraph32 for you (hurray!). As requested from before, made changes for insensitive text search from either starting symbol or as a substring. Also added address lookup in IDA.

Important changes to mouse-click operations:
- Right-click will now select your root node
- Double left-click will attempt to lookup the node in IDA (if you have it running in background).

Address lookup don't work.
Even do not switch to IDA window.

Right click seems not a good solution - as we have context menu or right click.
Also hiding all nodes completely is not good ideas as I now understand, just make them much lighter, so they won't clutter view.

Tried assuming "blue" colour to be root node but it doesn't work. Reason being that (in primer example), depth search begins at root and travels AWAY from node (note the arrow directions along edges). The blue root in primer, arrows all point TO the root... so even if I made that root automatically, setting depth of 1, 2, 3, etc... will still only show that one node and nobody else. I guess the only way around this is to do a reverse depth search.

Yes, as this example is make as calling xref to current identifier (and yes, in this case reverse search seem appropreate).
In case of "calling from" graphs all are ok.