GH1 firmware research volunteers required

The progress on new firmware is definitely encouraging.
I would like to see everyone involved be as professional as possible about this, similar to the magic lantern stuff on the camera side.
Also, maybe if you could upload the video to VIMEO or something, that would be helpful.
Though the compression might defeat the purpose of the test footage.
 
Thanks!



MJPEG @ 24fps is working? :shocked:
Or there are still "jumps" when panning and so?

MJPEG at 24fps still skips every 5th frame. Not complaining, just letting everyone know.

I have been testing changes to 1080p24 GOP but without any change in quality.

PTool 3.14

Version Change X
Native 24p/25p X
MJPEG 30fps->24fps X
VA Bitrate adjustment 20000000
VA Bitrate adjustment2 24000000
VA Bitrate top limit (20->25mbps) X
VA 1080p24 GOP Size (I've tried 2,5,8,10)

It's stable and even the bitrate goes up to 2.5 MB/s (for GOP size 2 and 5), but the quality isn't noticeably different. Yet.
 
The progress on new firmware is definitely encouraging.
I would like to see everyone involved be as professional as possible about this, similar to the magic lantern stuff on the camera side.
Also, maybe if you could upload the video to VIMEO or something, that would be helpful.
Though the compression might defeat the purpose of the test footage.

I recommend Dropbox. It's easy, available for all platforms, no download limits, etc.
 
+1. In addition to available alternatives, there is an unknown liabilility concern. Can everyone applying patches sign a disclaimer promising not to go after tester13 (not likely it will have much effect anyway ;) the first time something "stupid" happens? Ultimately, T13 makes his own decisions, but my suggestion is not to touch this one.

If something stupid happens due to the modified firmware the user that installed it after being properly warned about such risk is out of $660.00.

In the US it will cost you much more to say "hello" to a lawyer. ;)
 
If something stupid happens due to the modified firmware the user that installed it after being properly warned about such risk is out of $660.00.
In the US it will cost you much more to say "hello" to a lawyer. ;)
I was thinking along the lines of: bad battery installed, explodes, sprays user with melted lithium cobalt oxide, who then proceeds to sue Panasonic for not being dilligent enough in stopping anonymous hackers from luring innocent Panasonic customers into such dangerous risk-taking with dreams of mudless video, clean audio and who knows what else. So, yeah, my point is: don't touch it with a ten foot pole, especially a disassembler.
 
I was thinking along the lines of: bad battery installed, explodes, sprays user with melted lithium cobalt oxide, who then proceeds to sue Panasonic for not being dilligent enough in stopping anonymous hackers from luring innocent Panasonic customers into such dangerous risk-taking with dreams of mudless video, clean audio and who knows what else. So, yeah, my point is: don't touch it with a ten foot pole, especially a disassembler.



You wouldn't get sprayed with lithium. The largest risk of dangerous lithium precipitation is when the battery is charging. I should know, I designed battery chargers for LI-ION batteries for a couple of years.
 
This is a dumb question, I'm not into programing or anything like that..but what about the banding issue in underexposed areas (in low light situations), is that something that can be treated or its mostly hardware..thanks for all the work so far!
 
The fixed noise is a byproduct of the CMOS sensor. It's a hardware issue. However, the gain of the amplifiers/buffers between the CMOS and the processing add noise as well. Nobody knows for sure how much each plays into the fixed noise banding. It would take a serious hardware debugging to do so. I could do it but I'm not willing to take my camera apart at this point. Maybe when the warranty runs out I'll give it a go.

Most likely there won't be anything we can do about it.

Also, I'm not sure that the CMOS sensor itself is the limitation for the line scanning speeds that give us the infamous shutter skewing we know and hate. Since the sensor is technically a dumb device, a processor must be the one to do the work. The rolling shutter is probably an artifact of the speed ability of the processor to sample each line/pixel, process and output. It's likely a bandwidth limitation for the type/cost of the parts used. In short, I bet Pana used the cheapest parts they could use and still get decent video. Other recorders have used CMOS sensors without much or any rolling shutter(RED seems to have done it since the initial RED one came out with some accounts of rolling shutter which was fixed via firmware according to people who claim to have seen it). Panasonic's new pro camcorder also uses the same sensor as the GH1 and I would bet does not exhibit rolling shutter. The real question is: How much of the processing is software and how much is hardware? If it's software, pana or a firmware writer could essentially kill all the unused processes that were un-needed(such as still picture stuff) and then dedicate all of that CPU time to processing the video.
 
Last edited:
The fixed noise is a byproduct of the CMOS sensor. It's a hardware issue. However, the gain of the amplifiers/buffers between the CMOS and the processing add noise as well. Nobody knows for sure how much each plays into the fixed noise banding. It would take a serious hardware debugging to do so. I could do it but I'm not willing to take my camera apart at this point. Maybe when the warranty runs out I'll give it a go.

Most likely there won't be anything we can do about it.

Also, I'm not sure that the CMOS sensor itself is the limitation for the line scanning speeds that give us the infamous shutter skewing we know and hate. Since the sensor is technically a dumb device, a processor must be the one to do the work. The rolling shutter is probably an artifact of the speed ability of the processor to sample each line/pixel, process and output. It's likely a bandwidth limitation for the type/cost of the parts used. In short, I bet Pana used the cheapest parts they could use and still get decent video. Other recorders have used CMOS sensors without much or any rolling shutter(RED seems to have done it since the initial RED one came out with some accounts of rolling shutter which was fixed via firmware according to people who claim to have seen it). Panasonic's new pro camcorder also uses the same sensor as the GH1 and I would bet does not exhibit rolling shutter. The real question is: How much of the processing is software and how much is hardware? If it's software, pana or a firmware writer could essentially kill all the unused processes that were un-needed(such as still picture stuff) and then dedicate all of that CPU time to processing the video.



I feel almost exactly the opposite. I would think the fixed noise/banding is a software problem and the rolling shutting is a hardware problem.

The fact that we can take a still picture that doesn't exhibit banding issues means to me that it's not the sensor, it's something between the sensor and the SD card. So it's either a hardware bandwidth issue or it's software. Considering Panasonic sells high end video cameras I would think purposely crippling a consumer product is likely.

The rolling shutter problem exists everywhere, even in film to some degree. CMOS sensors are known to exhibit it, and only the highest quality and latest CMOS sensors can limit it to a triviality. It's not software.
 
The fixed noise is a byproduct of the CMOS sensor. It's a hardware issue. However, the gain of the amplifiers/buffers between the CMOS and the processing add noise as well. Nobody knows for sure how much each plays into the fixed noise banding. It would take a serious hardware debugging to do so. I could do it but I'm not willing to take my camera apart at this point. Maybe when the warranty runs out I'll give it a go.

Most likely there won't be anything we can do about it.

Also, I'm not sure that the CMOS sensor itself is the limitation for the line scanning speeds that give us the infamous shutter skewing we know and hate. Since the sensor is technically a dumb device, a processor must be the one to do the work. The rolling shutter is probably an artifact of the speed ability of the processor to sample each line/pixel, process and output. It's likely a bandwidth limitation for the type/cost of the parts used. In short, I bet Pana used the cheapest parts they could use and still get decent video. Other recorders have used CMOS sensors without much or any rolling shutter(RED seems to have done it since the initial RED one came out with some accounts of rolling shutter which was fixed via firmware according to people who claim to have seen it). Panasonic's new pro camcorder also uses the same sensor as the GH1 and I would bet does not exhibit rolling shutter. The real question is: How much of the processing is software and how much is hardware? If it's software, pana or a firmware writer could essentially kill all the unused processes that were un-needed(such as still picture stuff) and then dedicate all of that CPU time to processing the video.


This is true. Then, the M-X Sensor upgrade corrected it even more. So, I believe you're accurate, it can be both software and hardware yet not the responsibility of the actual sensor.

Barry_Green may know for sure.

Not an AF100 thread, but, this is why I have high hopes for improved rolling shutter, banding/FPN, etc in the AF100. Larger body to fit better processing, higher-priced item to justify cost to manufacture.
 
I feel almost exactly the opposite. I would think the fixed noise/banding is a software problem and the rolling shutting is a hardware problem.

The fact that we can take a still picture that doesn't exhibit banding issues means to me that it's not the sensor, it's something between the sensor and the SD card. So it's either a hardware bandwidth issue or it's software. Considering Panasonic sells high end video cameras I would think purposely crippling a consumer product is likely.

The rolling shutter problem exists everywhere, even in film to some degree. CMOS sensors are known to exhibit it, and only the highest quality and latest CMOS sensors can limit it to a triviality. It's not software.


FPN IS always present in a CMOS sensor. A clever use of post-processing could essentially get rid of it through different means.

http://en.wikipedia.org/wiki/Fixed-pattern_noise

Taking a picture is not the same as taking video. We would have to know exactly what Pana is doing when they take a picture anyway. They could very well be taking a full (global) shutter shot since they do indeed use a mechanical shutter as part of their process. The resources needed for a single picture is much less than would be needed for 24, 30 or 60 pictures a second, I.E. video.

Anyway, the CMOS sensor is just a matrix of pixels with wires connecting them in a big grid. An external device must scan each row and column in a specific pattern to read each pixel. An analog to digital stage takes the voltage and turns it into a datastream. The CPU then needs to turn all of the datastreams from each of the columns and rows into something it can process. This takes time and resources. Time and resources will be limited by the speed of the CPU, the amount of RAM, bandwidth of the communications, etc but this also includes all of the routines that the system is running.

So yeah you can say that the rolling shutter could be a hardware problem in that Pana likely used the slowest(cheapest) parts it could get away with, but it's more likely that their firmware is simply running too much stuff to spend a lot of time sampling the CMOS sensor. If they were to dedicate more CPU time to the sampling of the CMOS sensor they could likely reduce the rolling shutter. Global shutter would probably need a hardware redesign though.
 
FPN IS always present in a CMOS sensor. A clever use of post-processing could essentially get rid of it through different means.

http://en.wikipedia.org/wiki/Fixed-pattern_noise

Taking a picture is not the same as taking video. We would have to know exactly what Pana is doing when they take a picture anyway. They could very well be taking a full (global) shutter shot since they do indeed use a mechanical shutter as part of their process. The resources needed for a single picture is much less than would be needed for 24, 30 or 60 pictures a second, I.E. video.

Anyway, the CMOS sensor is just a matrix of pixels with wires connecting them in a big grid. An external device must scan each row and column in a specific pattern to read each pixel. An analog to digital stage takes the voltage and turns it into a datastream. The CPU then needs to turn all of the datastreams from each of the columns and rows into something it can process. This takes time and resources. Time and resources will be limited by the speed of the CPU, the amount of RAM, bandwidth of the communications, etc but this also includes all of the routines that the system is running.

So yeah you can say that the rolling shutter could be a hardware problem in that Pana likely used the slowest(cheapest) parts it could get away with, but it's more likely that their firmware is simply running too much stuff to spend a lot of time sampling the CMOS sensor. If they were to dedicate more CPU time to the sampling of the CMOS sensor they could likely reduce the rolling shutter. Global shutter would probably need a hardware redesign though.

I shouldn't have lumped fixed noise in with banding. Other than that, I stand by what I said.
 
Guys, please do no go to banding and rolling shutter things.
We can't fix them, so it is better to discuss in separate thread, especially then level of discussion is not very high.
From software point, preventing banding almost completely is entirely possible, but it requires costly calibration and either ADC adjustments or RAW video correction.
All current DSLRs do not have annough resources to do this.
Yet another approach is to remove line skipping and use full frame scaling using good algorithms.


I'am reading H264 encoder related stuff, especially VBR quality estimators.
We also know some audio related functions so, for AGC we can go from this.
Guys, no one still want to disassembly his GH1 and look for used CODEC?
As it can be best approach.

So, our targets:
Low level sensor setup routines, like scanning speed, fps, etc.
H264 encoder settings allowing to adjust quality estimator, I and P frames size allocation.
Trying to locate AGC (or limiter :) ) related stuff.
Video output functions research.
 
Last edited:
To Anyone

Can you provide small (5s) clips for all video resolutions and all framerates (plus all settings of compression)?
Including ALL resolutions of MJPEG (including very low ones).
Use original firmware without any patches.
I need this for research purposes.
Camera must be mounted on tripod and show same static scene.
 
as long as I've only changed the lang, would my video still be okay for testing? i can post by tonight/tomorrow.

Car3o, I believe that our new camera will be at your home today or tomorrow?

We also need high speed SD cards for me and our active testers. They'll be around $35 for each one.

Your video will be OK, yes, but we need AVCHD PAL ones also.
 
Back
Top