GH1 IDA Pro database research

Vitaliy,

I've been digging deeper into the code and I'm trying to figure out how to target my analysis. I've developed a theory I wanted to pass by you.

When the codec packages stream data for final assembly into the interlaced frames for progressive footage I assume that there are various intermediate buffers that are used. When taking a native 1080p frame the codec is going to chop it up into half-frame components and then reassemble into a 60i (or 50i) frame. I'm thinking that somewhere in this process a buffer is allocated assuming either a 720p frame (for 720p footage) of half a 1080p frame - both of which are smaller than a full 1080p frame. Either that, or there is code that attempts to choke the output to one of these levels. Obviously, somewhere along the line the correct encoding for a full 1080p frame has to exist, otherwise the camera wouldn't be able to produce the interlaced version either.

Does this approach make sense to you?

Chris
 
Vitaliy,

I think I may have found a bug in the firmware - screen capture from IDA attached...

Chris
 

Attachments

  • Bug1.jpg
    Bug1.jpg
    61.9 KB · Views: 0
No.
This seems to be scaler related constants.
MJPEG also uses 2080 for 1920 and 1440 for 1280.

I'll open MJPEG part soon (start of next week, most probably) so it'll be more clear.
 
I found this by back-tracing the AVCHD routines. What I can't figure out is why the 1280 is there, then, and there seems to be no corresponding 1920. The code seems to have provisions for modes not in use and I'm wondering if they are just missing something. Oh well, I'll wait for your new stuff and revisit.

Chris
 
Last edited:
cbrandin said:
Vitaliy,

Do you know which compiler was used to produce the GH1 firmware?

Chris
Click to expand...

As I understand it is Debug Factory Builder.

Generally MN103S processor module lacks two very important things - local variables and parameters determination.
And I almost forgot about cycles (it ignores corresponding commands :) )
Compiler passes first parameters always using registers (ala _fastcall option).
 
Vitaliy,

Another question. I've been analyzing the two video encoder and the TS Plug-ins. There are many similarities between the two video encoder routines except that one is much more complex than the other (i.e. it has many more routines appended). I figure it's because of one of two things: either one is for 1080 and the other for 720, or one is AVCHD and the other is MJPEG. I find it hard to believe that the 1080 could be that much more complex than the 720, so I'm gravitating toward the latter possibility. Also, the more complex video encoder has several constant tables that look like they could be for golomb encoding of video, etc... Do you have any thoughts on this?

Chris
 
Important addition

New database version released today (available at same address).

Opened up:
MJPEG related routines.
System routines (file opening, reading, closing, etc).
Plus one safe routine (can be used to attach any of your compiler routines that will be called upon menu item selection).
 
idc commqands (enter via shift-f2):
interrupts naming:
Code: 
MakeName    (0X40000000,    "RESET");
MakeRptCmt    (0X40000090,    "INT0 Vector");
MakeName    (0X40000090,    "INT0_40");
MakeRptCmt    (0X40000098,    "INT1 Vector");
MakeName    (0X40000098,    "INT1_40");
MakeRptCmt    (0X400000A0,    "INT2 Vector");
MakeName    (0X400000A0,    "INT2_40");
MakeRptCmt    (0X400000A8,    "INT3 Vector");
MakeName    (0X400000A8,    "INT3_40");
MakeRptCmt    (0X400000B0,    "INT4 Vector");
MakeName    (0X400000B0,    "INT4_40");
MakeRptCmt    (0X400000B8,    "INT5 Vector");
MakeName    (0X400000B8,    "INT5_40");
MakeRptCmt    (0X400000C0,    "INT6 Vector");
MakeName    (0X400000C0,    "INT6_40");
 
MakeRptCmt    (0X7BC00018,    "INT0 Vector");
MakeName    (0X7BC00018,    "INT0_7B");
MakeRptCmt    (0X7BC00020,    "INT1 Vector");
MakeName    (0X7BC00020,    "INT1_7B");
MakeRptCmt    (0X7BC00028,    "INT2 Vector");
MakeName    (0X7BC00028,    "INT2_7B");
MakeRptCmt    (0X7BC00030,    "INT3 Vector");
MakeName    (0X7BC00030,    "INT3_7B");
MakeRptCmt    (0X7BC00038,    "INT4 Vector");
MakeName    (0X7BC00038,    "INT4_7B");
MakeRptCmt    (0X7BC00040,    "INT5 Vector");
MakeName    (0X7BC00040,    "INT5_7B");
MakeRptCmt    (0X7BC00048,    "INT6 Vector");
MakeName    (0X7BC00048,    "INT6_7B");
 
Last edited by a moderator:
DaLiV

Can I ask you stupid question?
Why are you posting this?
All this names (IRQ, lang related things, and more) are present in full database.

I am specially opening database part by part so we could concentrate on actual problems
(for example, you already can write routines to allow user load parameters from SD card using menu item).
And it is much better to really do something useful.
You are so smart guy, and you can be very helpful.

P.S. I deleted all language related things in your post as this will remain closed info (between developers), ok?
 
Last edited:
may be that persist in "Full database", but you was shared partial - and many peoples have this only partial DB. So they seems need to knew which procedure for what, so they don't do same work twice. Ok if You was reserched thats, but other don't knew about have you done that or not, and don't knew about that locations, so your work in that case done by someone without real needs.
Sometimes another place in firmware can point in main place to something, that may be significant....

for writing of procedure need to knew more about currently existing functions (so they researched on shared partial base. as file operation/button processing/menu selection call addreses while not researched personally - so they act as blocking mechanism to do something that based on its ...)

P.S. sorry for language.
 
Last edited:
DaLiV said:
may be that persist in "Full database", but you was shared partial - and many peoples have this only partial DB. So they seems need to knew which procedure for what, so they don't do same work twice. Ok if You was reserched thats, but other don't knew about have you done that or not, and don't knew about that locations, so your work in that case done by someone without real needs.
Sometimes another place in firmware can point in main place to something, that may be significant....

for writing of procedure need to knew more about currently existing functions (so they researched on shared partial base. as file operation/button processing/menu selection call addreses while not researched personally - so they act as blocking mechanism to do something that based on its ...)

P.S. sorry for language.
Click to expand...

OK, just inform me that is required and reasons why you need this parts and I'll open them up(if I'll have them, of course). ok?
 
I re-examined the video encoder plug-ins. They are more similar than I had originally thought. It took me a while to figure out how they arrange class tables, but I finally got it. So now my conclusion is that they are both indeed related to AVCHD (you probably knew this). It appears that the second one (...PlugIn_0) is the 1080 24p one as it has no tables for H and L modes.

Chris
 
Yes, MJPEG code is very old and is not located in this areas.

Please, use proper name prefix (I suggest to use multiple prefixes ala AVCHD_Enc24_... and AVCHD_EncG_ ..).
It'll help later.
 
What I'm doing is using CLB... for names of items I don't fully understand (so I can find them later). After I figure them out I try to use naming consistent with your style.

Chris
 
Good idea.
In this case you can make IDC file.
And filter it out leaving only MakeName("CLB....") stuff.
It is easy to do.
Even better approach is to make IDC file from original version and provide only added or changed entries.
Or write separate script (you can look at script provided with mnIDE as example).
 
There is an area of the code I want to experiment with. The two captures show the equivalent code areas from the two AVCHD video encoders. There are constants relating to quality levels which are 264 and 190 for one codec and 234,168,117,and 93 for the other. The interesting thing is that the ratio between the first set and the second comes to the same ratio as the number of bits in 1/2 of a 1080 frame versus a full 720 frame. This leads me to wonder if these are the correct numbers for a 1/2 1080 frame, not the full frame you get when Native mode is checked. Other ratios, such as 50 vs 60 fps, or the pulldown ratio don't fit. If it were based on 24p/60i vs 60p then I would expect to see something that differentiates between 25p/50i and 24p/60i, and I don't see anything.

I've been thinking that doubling the first set of numbers to 528 and 380 might make sense.

I hate to bother you with this, but until I can patch these myself I have to.

Chris
 

Attachments

  • Const1.jpg
    Const1.jpg
    28.5 KB · Views: 0
  • Const2.jpg
    Const2.jpg
    44.7 KB · Views: 0
You must log in or register to reply here.
Back
Top