Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - reddeercity

#1
Found the Vertical Stretch & Compressed in 3x3 , should be very useful in the HDMI development , maybe a module even who knows  ;D
 

Also found a HDMI Regs that give a Multi View , pretty interesting maybe different preview for 10x ?
not too sure but it goes to show you how powerful the HDMI chip really is , now to tap in to that.
 
#2
just a litle update , it looks like all Reg's with C0f14xxx Control the total HDMI screen which would be the HD Vram (if i'm not mistaken) the total width including blackbar the on the right & left
So far C0f140xx to C0F142xxSeem to have a Horizontal distortion or skew from left leaning to right leaning.
C0F11308 does a Vertical Stretch , seems like its changing the pixel from square (1:1) to a 1:2 or 1:1.5
maybe enough to stretch the 720p50 down close to full vertical.

But i'm really looking for is to change the Aspect Ratio from 3:2 to 16:9
i see it the logs , the base Aspect Ratio is 3:2 (because its a Photo cam first , Video Second)
At least as far as the HDMI is concern , Liveview is 3:2 or 16:9 depending if in photo or video mode.
If i can find it then i would be portable across the ml D4 & D5 (since there are close at least the 5D2 & 5d3 are.)
#3
Seem that 720p50 work good , (it was by total luck that i got this to work this well in a short time)
Here the Regs i used
c0f14210 0x277a --> 0x277f
c0f14220 0xe1 --> 0x15
c0f14254 0x32090231 --> 0x2208fc01


I crop the bottom to 1280x535 then i vertcally sterched to 1080 , that ended up as 1280x1080 50FPS
4x3 Aspect Ratio , that telling me the HD buffer need to modified just like raw in crop_record
anyways i think what happening is the HDMI chip is resampling the 1650x1080(HD Buffer) to 1280x720p50
Its clean , definitely progressive scan and at 50fps, it also works in default Crop_Mode(2150x1074)
More work is needed , but i good start. I guess it could a good focusing aid .
   
#4
Looks like i'm making some progress :)
Didn't know that the 5d2(D4) has 720p 59.94 fps HDMI output !
That I2c HDMI chip has a few possibility once we know have to configure it correctly.
So it appears i found full width HDMI in 3x3 mode but in 1280x720p 59.94 fps
it seem to fuul the full width , just need to adjust the verital offset & the Hozonal offset.
I have found the Offset also but didn't have time today to contine to refine it .
below are 2 Video links , one is the HDMI Capture thought my Aja Kona PciE card on my PC
Captured to 10 bit ProRes 422 proxy (53 Mb/s) then compressed it to MP4 720p 59.94fps (5Mb/s)
the other video clip is from my iPhone (4K to 1080p30) to show it working.


 5D2_HDMI_Full_with_720p59.94_fps.MP4 HDMI Capture file 60MB


iPhone video iPhone file 28 MB

First i put the HDMI in to progressive scan (1920x1080p 29.97fps)


c0f14254 0x32090231 ---> 0x22083232The Next Regs take some time to fine (and that was pure luck by the way)
c0f14210 0x277A ---> 0x277Bthat change to 720p 59.94fps , by the way i can do 720p50 108025i but i had no image there.
the very strange thing also i found the spot where i was getting 1080p59.94 but it was coming in and out with no real image


 
#5
Small update about a few things i'm working on , some interesting results with some possibility's
1St, Liveview (HD Vram) looking for a reg or Reg's to turn 3:2 A.R off to 16x9 (tell you latter why i think its a matter of turning off a switch (code wise or reg maybe), the other thing i may need a bigger HD Vram buffer , just using the canon default one , which could be why my results are limited.
This was with the HDMI connected to my led monitor @ 60i in 3x3 mode full frame
IMG-4422-small" border="0
I can move the whole HD liveview to the Left fully , (when recording raw video with the HD liveview like this doesn't effect the raw image it stay the centered etc. ...)

IMG-4421-small" border="0

Moved over to the Right fully , same as above no problem recording raw video , raw image untouched by
HD Vram reg's.

Found this to be very interesting that need more in depth investigation , i found what the real
width of the HD vram is , (this was when i was recording H264)
if i can found the right routines i can get HDMI to match 
IMG-4293-small" border="0

Lastly a simple quick bench mark for the CF card with the modified reg for max write speed
or as match as the overhead will allow , it more then normal , kind of impressive.
Usually don't hit 105MB/s in the bench mark , in photo mode by the way

 IMG-4371-small" border="0
#6
Looks like i may have found the lossless routine for 5d2 or should i say the missing parts
14.509.246  ShootSsDev:ff162f04:a7:03: sssExecuteMem1ToRawPath(26599)
14.509.308  ShootSsDev:ff162f50:a7:02: LOSSLESS_FLAG
14.509.386  ShootSsDev:ff163324:a7:03: ProcessTwoInTwoOutLosslessPath(R) Start(26599)
14.509.395  ShootSsDev:ff163330:MMIO : [0xC022200C] <- 0x00000012
14.509.419  ShootSsDev:ff3dd2c0:00:00: *** LockEngineResources(6830d8) x16:
14.509.440  ShootSsDev:000b06c8:00:00:      1)    10000 (read channel 0x8)
14.509.453  ShootSsDev:000b06c8:00:00:      2)        d (write channel 0x16)
14.509.466  ShootSsDev:000b06c8:00:00:      3)        2 (write channel 0x2)
14.509.480  ShootSsDev:000b06c8:00:00:      4)    30001 (read connection 0x1)
14.509.495  ShootSsDev:000b06c8:00:00:      5)    2002d (write connection 0x2d)
14.509.511  ShootSsDev:000b06c8:00:00:      6)    20016 (write connection 0x16)
14.509.520  ShootSsDev:000b06c8:00:00:      7)    50034 (?)
14.509.529  ShootSsDev:000b06c8:00:00:      8)    5002d (?)
14.509.539  ShootSsDev:000b06c8:00:00:      9)    50010 (?)
14.509.548  ShootSsDev:000b06c8:00:00:     10)    90001 (?)
14.509.559  ShootSsDev:000b06c8:00:00:     11)   230000 (?)
14.509.569  ShootSsDev:000b06c8:00:00:     12)   160000 (?)
14.509.580  ShootSsDev:000b06c8:00:00:     13)   260000 (?)
14.509.591  ShootSsDev:000b06c8:00:00:     14)   260001 (?)
14.509.601  ShootSsDev:000b06c8:00:00:     15)   260002 (?)
14.509.612  ShootSsDev:000b06c8:00:00:     16)   260003 (?)

14.633.967  ShootSsDev:ff3dc84c:00:00: *** UnLockEngineResources(6830d8) x16:
14.633.987  ShootSsDev:000b06c8:00:00:      1)    10000 (read channel 0x8)
14.634.001  ShootSsDev:000b06c8:00:00:      2)        d (write channel 0x16)
14.634.013  ShootSsDev:000b06c8:00:00:      3)        2 (write channel 0x2)
14.634.028  ShootSsDev:000b06c8:00:00:      4)    30001 (read connection 0x1)
14.634.043  ShootSsDev:000b06c8:00:00:      5)    2002d (write connection 0x2d)
14.634.059  ShootSsDev:000b06c8:00:00:      6)    20016 (write connection 0x16)
14.634.069  ShootSsDev:000b06c8:00:00:      7)    50034 (?)
14.634.078  ShootSsDev:000b06c8:00:00:      8)    5002d (?)
14.634.087  ShootSsDev:000b06c8:00:00:      9)    50010 (?)
14.634.097  ShootSsDev:000b06c8:00:00:     10)    90001 (?)
14.634.107  ShootSsDev:000b06c8:00:00:     11)   230000 (?)
14.634.118  ShootSsDev:000b06c8:00:00:     12)   160000 (?)
14.634.129  ShootSsDev:000b06c8:00:00:     13)   260000 (?)
14.634.139  ShootSsDev:000b06c8:00:00:     14)   260001 (?)
14.634.150  ShootSsDev:000b06c8:00:00:     15)   260002 (?)
14.634.161  ShootSsDev:000b06c8:00:00:     16)   260003 (?)

different terminology between D4 & D5 cams
sssExecuteMem1ToRawPathLOSSLESS_FLAG
the other part , "TTJ" stuff missing in my code plus the "sss state"
14.645.411  ShootSsDev:000178e4:00:00: *** SSSState: (9) --10--> (2)          ff1639d8 (x=65ffcc z=65ffcc t=0)
14.645.436  ShootSsDev:ff163a14:a7:03: sssCompleteRawToLcdJpeg(26599)
14.645.456  ShootSsDev:ff163844:a7:03: sssStopMem1ToJpegPath(26599)
14.645.471  ShootSsDev:ff290cb0:MMIO : [0xC0F26408] -> 0x01596EE0
14.645.472  ShootSsDev:ff290cb0:MMIO : [0xC0F26508] -> 0x03201008
14.645.495  ShootSsDev:ff3cf300:16:03: [TTJ] STOP WR1:0x3201008 WR2:0x1596ee0
14.645.499  ShootSsDev:ff290cb0:MMIO : [0xC0F26A08] -> 0x0124E704
14.645.501  ShootSsDev:ff290cb0:MMIO : [0xC0F04A08] -> 0x0ACF938E
14.645.521  ShootSsDev:ff3cf32c:16:03: [TTJ] STOP RD1:0xacf938e RD2:0x124e704

14.659.528  RearShtDev:ff20d524:8f:03: RemoveObject : SRAW_OBWB not found
14.659.545  RearShtDev:ff20d544:8f:03: RemoveObject : LRAW_YUV not found
14.659.554  RearShtDev:ff20d564:8f:03: RemoveObject : MRAW_YUV not found
14.659.562  RearShtDev:ff20d584:8f:03: RemoveObject : SRAW_YUV not found
14.659.572  RearShtDev:ff20d5a4:8f:03: RemoveObject : JPEG_LF_YUV not found
14.659.582  RearShtDev:ff20d5c4:8f:03: RemoveObject : JPEG_LN_YUV not found
14.659.591  RearShtDev:ff20d5e4:8f:03: RemoveObject : JPEG_MF_YUV not found
14.659.599  RearShtDev:ff20d604:8f:03: RemoveObject : JPEG_MN_YUV not found
14.659.611  RearShtDev:ff20d9dc:8f:03: RemoveObject : JPEG_SF_YUV not found
14.659.621  RearShtDev:ff20d9fc:8f:03: RemoveObject : JPEG_SN_YUV not found
14.659.629  RearShtDev:ff20da1c:8f:03: RemoveObject : JPEG_S2_YUV not found
14.659.638  RearShtDev:ff20da3c:8f:03: RemoveObject : JPEG_S3_YUV not found

Jpeg Compression Levels ?, seems to right compaired to my Canon SDK kit

namespace Canon.Eos.Framework
{
    public enum EosCompressLevel : byte
    {
        Unknown = 0xF,
        JpegUncompressed = 0,
        JpegCompression1 = 1,
        Normal = 2,
        Fine = 3,
        Lossless = 4,
        SuperFine = 5,
        JpegCompression6 = 6,
        JpegCompression7 = 7,
        JpegCompression8 = 8,
        JpegCompression9 = 9,
        JpegCompression10 = 10,
    }
}
So maybe the Black Box can be opened finally  :D 

Plus I've taken a Deep Drive in to the Live View World , more precisely the HDMI in 3x3
looking into removing the Side Black bars , so the HDMI should go from 1650x1080 to 1920x1080 16x9 (no black bars)
I've come close , but haven't found the regs to open up the Horizontal , found the Vertical ones , but that's not what i'm after.
Don't expect anything for a while , being working on this for a week already and just scratched the surface plus there's many rabbit hole to fall in to.
 






#7
poking the 50D for the same reg



0xc062850c Its the  same as the 5D2 ,
50D results
0x1 = 78-83MB/s
0x3 = 55
0x5 = 43.3
0x11 = 16MB/s
0x21 = 8.8MB/s
0x1302 = 25.5MB/s
0x1402 = 78-83MB/s
0x2402 = 15MB/s
0x1801 = 78-83MB/s
0x1807 = 18MB/s
More or less the same , maybe the 40D has the same Reg , i know it suffers from low CF bus speed

 
#8
Did some test on the CF card controller reg's , What i though was the right reg
turn out it was wrong , the log wasn't correct . But i did find the reg that controls the
the cf bus speed , i can control it from 82.3 MB/s down to 5.4 MB/s ,
that right i said 82.3MB/s to 5.4 MB/s !
normally with get 68 MB/s to 72MB/s in some cases up to 75MB/s ( that's the average)
I'm about to get 82.3MB/s (i suspect this maybe UDMA 7 cause 75MB/s is the default now & that UDMA 6)
There a lot of overhead here , i think i'm going to poke at the reg & see if i can reduce the overhead
by turning off certain ones i've been researching if its necessary or not.

back to the Reg i found to work , i just used the last 4 digic from the 5D3 reg's
the 0x1 seems the fastest so far , i'm still poking this reg 
 

Here a list of what of the offsets that gear down the CF card controller bus.
tested 3x crop default mode (2150x1076 @23.976fps at 14bit)
had a 78 frame buffer
0x1 = 78-81MB/s
0x2 = 68-71MB/s
0x3 = 57MB/s
0x4 = 49MB/s
0x5 = 42MB/s
0x6 = 38MB/s
0x7 = 33.9MB/s
0x8 = 30MB/s
0x9 = 25.6MB/s
0xa = 25MB/s
0xb = 23.4MB/s
0xc = 22MB/s
0xd = 20MB/s
0xe = 19MB/s
0xf = 18MB/s
0x10 = 17MB/s
0x11 = 16MB/s
0x12 = 15.5MB/s
0x13 = 14.6MB/s
ox14 = 14MB/s
0x15 = 12.9 - 13.4MB/s
0x16 = 13MB/s
0x17 = 12.4MB/s
0x18 = 11.9MB/s
0x1a = 11.1MB/s
0x1b = 10.7MB/s
0x1c = 10.4MB/s
0x1d = 10.1MB/s
0x1e = 9.8MB/s
0x1f = 9.4MB/s
0x20 = 8.9MB/s
0x21 = 8.8MB/s
0x22 = 8.7MB/s
0x23 = 8.2MB/s
0x24 = 8.0MB/s
0x25 = 7.6MB/s
0x26 = 7.8MB/s
0x27 = 7.0MB/s
0x28 = 7.3MB/s
0x29 = 7.1MB/s
0x2a = 6.9MB/s
0x2b = 6.8MB/s
0x2c = 6.6MB/s
0x2d = 6.5MB/s
0x2e = 6.4MB/s
0x2f = 6.2MB/s
0x30 = 6.0MB/s
0x31 = 6.1MB/s
0x35 = 5.6MB/s
0x38 = 5.4MB/s

Some other i poked
0x1021 = 18MB/s
0x1022 = 12MB/s
0x121 = 80MB/s
0x1201 = 82.3MB/s
before i thought 0xC0620200 was correct , to control the card bus ,
that's wrong,  0xc062850c is correct at least right now , unless i found something different.
#9
Look like i found the total CF Card routine in a startup log for my 5D2
Seems to have the "DesiredTuple" configuration I'm looking for
now to figure out what & where the offsets are set by which Reg's
 Seems 0x41 is the offset , or is it for UDMA 6.0 maybe 0x51 or 0x14 is UDMA 7.0 ?
Anyways i'll do some testing tomorrow
 
CSMgrTask:22:03: ---- CFEventHandler(ID=0:Event=8) ----
        CSMgrTask:22:01: CF_ResetCard SUCCESS
        CSMgrTask:22:01: SearchTuple: DesiredTuple=0x22, Next=0
        CSMgrTask:22:01: SearchTuple: SUCCESS
        CSMgrTask:22:01:              Offset=0x7e, Code=0x22, Link=0x2
        CSMgrTask:22:01: GetTupleData: DesiredTuple=0x22
        CSMgrTask:22:01:               Offset=0x7e, TupleDataMax=0x100
        CSMgrTask:22:01: SearchTuple: DesiredTuple=0x22, Next=1
        CSMgrTask:22:01: SearchTuple: SUCCESS
        CSMgrTask:22:01:              Offset=0x86, Code=0x22, Link=0x3
        CSMgrTask:22:01: GetTupleData: DesiredTuple=0x22
        CSMgrTask:22:01:               Offset=0x86, TupleDataMax=0x100
        CSMgrTask:22:01: SearchTuple: DesiredTuple=0x15, Next=0
        CSMgrTask:22:01: SearchTuple: SUCCESS
        CSMgrTask:22:01:              Offset=0x2c, Code=0x15, Link=0x23
        CSMgrTask:22:01: GetTupleData: DesiredTuple=0x15
        CSMgrTask:22:01:               Offset=0x2c, TupleDataMax=0x100
        CSMgrTask:22:05: [CIS] MakerInfo  : KINGSTON
        CSMgrTask:22:05: [CIS] VersionInfo: ULTIMATE CF CARD 16G
        CSMgrTask:22:01: SearchTuple: DesiredTuple=0x1a, Next=0
        CSMgrTask:22:01: SearchTuple: SUCCESS
        CSMgrTask:22:01:              Offset=0x90, Code=0x1a, Link=0x5
        CSMgrTask:22:01: GetTupleData: DesiredTuple=0x1a
        CSMgrTask:22:01:               Offset=0x90, TupleDataMax=0x100
        CSMgrTask:22:01: RequestConfiguration: pLStorage=0x684eac
        CSMgrTask:22:01:                       ConfigBase=0x200, StatusReg=0x0
        CSMgrTask:22:01:                       PinRepReg=0x0, CopyReg=0x0
        CSMgrTask:22:01:                       ConfigIndex=0x1, Present=0xf
        CSMgrTask:22:01: RequestConfiguration: Base = 200, Data = 41
        CSMgrTask:22:01: RequestConfiguration: SUCCESS
        CSMgrTask:22:01: CF_RequestConfiguration: err=0x0
        CSMgrTask:22:01: ConfigIndex = 1 Match
        CSMgrTask:22:01: CF_DeviceCreate: StorageID=0, TotalBlks=0, HiddenBlk=0
        CSMgrTask:22:01:                   WriteProtect=0, RotatingDevice=0
        CSMgrTask:22:01: cfSoftReset( 0 )
        CSMgrTask:22:01: cfSoftReset SUCCESS
        CSMgrTask:22:01: &CurCardInfo=0x4c9f0
        CSMgrTask:22:03: Word164 = 0x8d9b
        CSMgrTask:22:05: [ID:Firmware Revision] = Ver6.02K
        CSMgrTask:22:05: [ID:Model Number] = ULTIMATE CF CARD 16GB                   
        CSMgrTask:22:05: IDE = 4, PCMCIA = 80, UDMA = 6
        CSMgrTask:22:03: Cyl=16383, Hds=16, Trk=63, nSec=31227840, Ms=1
        CSMgrTask:22:01: cfDecideTiming: UDMA Mode 6 (CFA4.0)
        CSMgrTask:22:01: cfDecideTiming: UDMA Mode 6 (CFA4.0)
        CSMgrTask:22:03: CF_GetAccessTiming : DatTim = 3, DatMod = 6
        CSMgrTask:22:05: cfIdentifyDrive: Cache Support
        CSMgrTask:22:05: cfIdentifyDrive: Idle Command(500mSec)
        CSMgrTask:22:05: cfIdentifyDrive: Set UDMA( Mode=6 )
        CSMgrTask:22:01: pBlkDev=0x685200
        CSMgrTask:22:03: nBlocks=31227840, bytesPerBlk=512
        CSMgrTask:22:03: blksPerTrack=63, nHeads=16
        CSMgrTask:21:01: [fsuDeviceAdd] (0)
        CSMgrTask:22:01: cfReadBlk: st=0, num=1, ofst=0
        CSMgrTask:21:01: fsuGetPart: default 1
        CSMgrTask:21:01:             nBlocks = 31227840, blkOffset = 63
#10
Have a look this jpcore that what we have to work with.
Walter right , D4 is limited in CPU processing power , that's why there's encoder chips
on the main board ,the only way to get a customs codec is to re-flash the rom with the codec code.
not a option , but the JPcore chip does has pretty good compression.
Thur i know it have the ability 4.2.2 but it can do RGB(4.4.4) whether that 8bit or 16bit
but once again as Walter say's "its a block box" , So i'm tied to the canon's routine's
I do belive thou the MPU has a lot to do with the JPcore also , if i could understand the MPU string code there use , (its numbers & letters) i could understand the jpcore more.   
#11
Tried the CF card Reg's , did see a little increase but not what i'm expecting
Basically i just recorded the 3X crop (5x zoom) @ 2152x1074 @23.976fps 14bit (default bit rate)
which requires 95MB/s i do believe , i was pecking as high as 85MB/s , average was 76.73MB/s which is good. I'm looking for at least 95MB/s
(i don't thing D4 will ever see 130MB/s , but 95 to 110MB/s seems achievable) there a lot of overhead on 5D2 as much as 20MB/s to 30MB/s
i have old documents that show this from a1ex back 5-6 years ago(i need to search for it) Normal Average write on 5D2 is 66MB/s to 68MB/s with MLV_Rec ,
the old first gen raw record max speed was 73MB/s (all @ 14bit)So if finding the correct reg's for UDMA7 seems out of reach  then i can start looking at reducing the overhead .
And i have gone down the path of overclocking the CF controller yet , i would prefer to easily set the UMDA by a simple over ride of regs .
With 0xc0620202
# Config file for module mlv_rec (MLV_REC.MO)
mlv.video.enabled = 1
mlv.res.x = 13
mlv.write_speed = 7673
mlv.preview = 2
mlv.display_rec_info = 2
mlv.buffer_fill_method = 0
Had pecking around 83MB/s

# Config file for module mlv_rec (MLV_REC.MO)
mlv.video.enabled = 1
mlv.res_x = 14
mlv.write_speed = 6644
mlv.display_rec_info = 2
mlv.warm_up = 2
mlv.buffer_fill_method = 0
Without any CF Card controllerreg's applied

# Config file for module raw_rec (RAW_REC.MO)
raw.video.enabled = 1
raw.res.x = 14
raw.write.speed = 7318
raw.preview = 1
raw.warm.up = 2
raw.bpp = 12
OLd Raw_Record (it was the fastest to date)
and again this Average write speed not peck or idle write speed.
So if i can get a 10MB/s average increase in write speed with one reg (guessing/iuck )
after some more investigation hopefully i can more  :) 

#12
Looks like i my have found the correct reg's for CF card UDMA

CFATA] at CSMgrTas:FFB8BD98:FFB8BD94 [0xC0620202] <- 0x0       : ???
[CFATA] at CSMgrTas:FFB8BDB0:FFB8BDAC [0xC0620204] <- 0x0       : ???
[CFATA] at CSMgrTas:FFB8BDC8:FFB8BDC4 [0xC0620206] <- 0x0       : ???

Before we used the D5 5D3 base Reg
0xC062850Cbelow are configation for udma
https://www.magiclantern.fm/forum/index.php?msg=206010
+0x850C [32]  UDMA access timing
                 UDMA 0: 7D: 0x1213 5D3: 0x1001616
                 UDMA 1: 7D: 0x0C0C 5D3: 0x1000F0E
                 UDMA 2: 7D: 0x0909 5D3: 0x1000B0B
                 UDMA 3: 7D: 0x0607 5D3: 0x1000808
                 UDMA 4: 7D: 0x0404 5D3: 0x1000505
                 UDMA 5: 7D: 0x0203 5D3: 0x0000303
                 UDMA 6: 7D: 0x0202 5D3: 0x0000202
I suspect the offsets to be the same , but the base is different
I found in a  FA_CaptureTestImage Log i had for while .

How do i know these are right , will after "0xC0620202"
the next bit of log show the successful configuration
[   CSMgrTask:ffb8bde0 ] (22:01) RequestConfiguration: SUCCESS
[   CSMgrTask:ffb8b958 ] (22:01) CF_DeviceCreate: StorageID=0, TotalBlks=0, HiddenBlk=0
[   CSMgrTask:ffb8b970 ] (22:01)                   WriteProtect=0, RotatingDevice=2
[   CSMgrTask:ffb89aec ] (22:01) cfSoftReset( 0 )
But i don't think that its the only one needed to change configuration
[CFATA] at CSMgrTas:FFB8BD04:FFB8BD04 [0xC0628100] -> 0x0       : ???
[CFATA] at CSMgrTas:FFB8BD0C:FFB8BD04 [0xC0628100] <- 0x0       : ???
[CFATA] at CSMgrTas:FFB8BD18:FFB8BD18 [0xC0628100] <- 0x0       : ???
[CFATA] at CSMgrTas:FFB8BD24:FFB8BD24 [0xC0628100] -> 0x0       : ???
[CFATA] at CSMgrTas:FFB8BD2C:FFB8BD24 [0xC0628100] <- 0x2       : ???
[CFATA] at CSMgrTas:FFB8BD38:FFB8BD38 [0xC0628100] <- 0x2       : ???
[CFATA] at CSMgrTas:FFB8BD48:FFB8BD44 [0xC0628044] <- 0x0       : Interrupt related?
[CFATA] at CSMgrTas:FFB8BD5C:FFB8BD54 [0xC0620200] <- 0x41      : ???
[CFATA] at CSMgrTas:FFB8BD68:FFB8BD68 [0xC0620200] -> 0x0       : ???
i think we may need these also , but i need to check farther ,
the first one to change is the 0xC062020x and see what happen
I try and test this tomorrow and see if this correct.

Edit: here the Log file
https://bitbucket.org/reddeercity/crop_rec_5d2_50d/downloads/FA_CaptureTestImage.txt
#13
Quote from: SoulState on July 18, 2024, 02:25:31 AMI tried this too, but for 50d with no luck, well, partially, posted image with artifacts (jagged edges) some pages ago.
Also no luck at all with 3.5k preset build (all pinky image), moreover, if i turn on fps override, and change fps from default, its getting worse - all screen and record with diagonal stripes. Some modules also conlficting in this build (links error or something)
All crop_rec preset are tune to the framerate i set , it can not be changed !
its has to do with sensor's width x  height frame size limitations  plus Liveview,
certain frames size are tune either 24fps or 48fps(hi-speed framerate), there no offsets
to change framerate, it a whole kettle of fish to have offset framerates , the coding
would take a very long time (time i don't have) i have to distribute my time equally over the
things i need to finish (raw compression(mlv_lite)1x3 crop_record plus better preview image,etc....
i just don't have time for a new function.

I also notice the 50D crop_rec module is a little glitchy , if you have issue just clear your setting
specially  menu setting , the direct draw in liveview is not refreshing properly and some of the
setting don't show up in lower bottom of screen .
I'll also work on a updated crop_rec to fix some bugs to switching better between presets .
for the 50D. 
edit: i should be able to increase the frame rate on the hi-speed framerate from 48 tp 60fps and maybe a little bit more (70 maybe or even 75fps)
on;y reason why i can do this is because of the smaller sensor APS-C 1.6x crop factor
#14
This was a very learning experience! Show how thing are interconnected and simple change can made a string of thing get difficult  ???
Quote from: names_are_hard on July 13, 2024, 07:06:54 AMYou're trying to call the function get_ms_clock_value(), but the compiler cannot find it.

You'll need to check whatever source you're using, but it may be that this function has been renamed to get_ms_clock().
In short that's what i did and it complied , but to get to that point just what to explain
Would i had to do to understand what i was doing (its no good changing something if you don't know what go on , you need to fellow the bread crumbs even thou it may come to the same conclusion.)

So let dive a little deeper here , maybe this will help others or newbie/knobs to look in the code and make changes there's selves.
So to get started I when to the 1st line the error was "mj_rec.c:479:16:" and with help from @names_are_hard  about the function "get_ms_clock_value()" could not be found .
so i had to find where the "get_ms_clock_value" this was or a piece of it e.g. "get_ms_clock"

At the head of the file there's included other files to work in conjunction with the "c" to work.
#include <module.h>
#include <dryos.h>
#include <bmp.h>
#include <menu.h>
#include <config.h>
#include <property.h>
#include <raw.h>
#include <shoot.h>
#include <zebra.h>
#include <beep.h>
#include <lens.h>
#include <focus.h>
#include <string.h>
#include <battery.h>
#include <powersave.h>
#include "../lv_rec/lv_rec.h"
#include "../mlv_rec/mlv.h"
#include <patch.h>
#include "edmac.h"
#include "edmac-memcpy.h"

I had to compare each file we my newer source files until i found where the differences was.
/** timing */
/* todo: move to a separate file */
int get_seconds_clock();
int get_ms_clock_value();
uint64_t get_us_clock_value();
int get_ms_clock_value_fast();
int should_run_polling_action(int period_ms, int* last_updated_time);
void wait_till_next_second();
Found it !! in DryOS.h , @Ant123 had a older version of ML and this was moved , now I had to find
where it was move to , (at this point getting scared this would mess everything up and would have to major work to get to compile  :(  )
I look at my Dryos.h file and the the only difference was it had a file called "timmer.h"
Look in the source file and there it was  :D
there the "get_ms_clock"
int get_seconds_clock();
int get_ms_clock();    /* millis() on arduino */
uint64_t get_us_clock();
so now I'm confident that the chances will work because i found how this all connects

The Question is did all this work , kind of . The Module compiled , loaded on my 5D2 & 50D
didn't crash lockup , that good.
Menu loaded , enabled it was able to save a .avi file but there a problem with getting the video stream ,It looks like its hard code for the address on 450D trying to save a frame 848x560
see below , but not content .
General
Complete name                            : C:\Users\i5Dell\Desktop\MJpeg_Module_D4\MJREC.AVI
Format                                   : AVI
Format/Info                              : Audio Video Interleave
File size                                : 4.01 KiB
Writing application                      : Magic Lantern
Moti                                     : PEG Movie recorder module

Video
ID                                       : 0
Format                                   : JPEG
Codec ID                                 : MJPG
Width                                    : 848 pixels
Height                                   : 560 pixels
Display aspect ratio                     : 3:2
Color space                              : YUV
Compression mode                         : Lossy

So Ill need to refine this module , its pretty rough yet . it seem to be ok with crop_record module
so it need the address of the jpeg/hd buffer similar to mlv_rec with the raw buffer.

5D2


50D


mj_rec.cfg
# Config file for module mj_rec (MJ_REC.MO) mj.rec = 1so i know it loaded & (working ?)

Finally load the .avi in to an HeX editor and this is what i got
so its works or the .avi writer is work at least

RIFF....AVI LISTÀ...hdrlavih8...ÿÿÿÿ............................P...0...................
LISTt...strlstrh8...vidsmjpg............è....................'..............strf(...(...P...0.......MJPG.½..................
LIST....INFOISFT....Magic [email protected] JPEG Movie recorder module...............................
IC......2024-07-14 01:36:54 U.JUNK€............

...LIST....moviidx1....

Its really not too bad , going to need to do some work on the address thing , and hoping there's a way to tune the biterate also . 

#15
Quote from: names_are_hard on July 13, 2024, 07:06:54 AMYou're trying to call the function get_ms_clock_value(), but the compiler cannot find it.

You'll need to check whatever source you're using, but it may be that this function has been renamed to get_ms_clock().
Thanks that help a lot , I'll check my source and see if this has happen .
 :)
#16
Trying to compile the Mjpeg module , it almost compiled using my latest crop_rec 4k etc... code
has 2 error that stop it from compiling , not sure how to solve.
Will here what is says , its line 479:16 & 564:17 . I'll link the source after the errors i post

david@reddeercity:~/5D2-50D-Crop_Rec_4k_fix_raw.c_error_7-19-2020/magic-lantern_reddeercity_5d2-50d_4k-crop_rec/modules/mj_rec$ make zip
Using /usr/bin/arm-none-eabi-gcc (from PATH).
[ RM dir   ]   /home/david/5D2-50D-Crop_Rec_4k_fix_raw.c_error_7-19-2020/magic-lantern_reddeercity_5d2-50d_4k-crop_rec/modules/mj_rec/zip/
mkdir -p /home/david/5D2-50D-Crop_Rec_4k_fix_raw.c_error_7-19-2020/magic-lantern_reddeercity_5d2-50d_4k-crop_rec/modules/mj_rec/zip
[ MKDIR    ]   modules_install_dir
Updated HGVERSION
[ README   ]   module_strings.h
[ CC       ]   mj_rec.o
mj_rec.c: In function 'mjpegSetup':
mj_rec.c:367:58: warning: implicit conversion from 'float' to 'double' to match other operand of binary expression [-Wdouble-promotion]
  rf->aviheader->dwMicroSecPerFrame = (uint32_t)(1000000.0/fps);
                                                          ^
mj_rec.c:372:49: warning: implicit conversion from 'float' to 'double' to match other operand of binary expression [-Wdouble-promotion]
  rf->avistreamheader->dwRate = (uint32_t)(1000.0*fps);
                                                 ^
mj_rec.c: In function 'mjpegCloseFile':
mj_rec.c:438:67: warning: mj_rec.c: In fcomparison between signed and unsigned integer expressions [-Wsign-compare]
   if (FIO_WriteFile(rf->fd, rf->index, *rf->pindex_real_size + 8) != *rf->pindex_real_size + 8)
                                                                   ^~
mj_rec.c: In function 'mjpeg_video_rec_task':
mj_rec.c:479:16: error: implicit declaration of function 'get_ms_clock_value' [-Werror=implicit-function-declaration]
   OldFioTime = get_ms_clock_value();
                ^~~~~~~~~~~~~~~~~~
mj_rec.c: In function 'process_frame':
mj_rec.c:535:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   if (max_frame_size < lvsize)
                      ^
unction 'mjpeg_frame_rdy':
mj_rec.c:560:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
  lvbuf = MEM(0x8308);
        ^
mj_rec.c:564:17: error: implicit declaration of function 'get_us_clock_value' [-Werror=implicit-function-declaration]
  NewFrameTime = get_us_clock_value();
                 ^~~~~~~~~~~~~~~~~~
mj_rec.c: In function 'mj_rec_polling_cbr':
mj_rec.c:682:15: warning: unused variable 'filename' [-Wunused-variable]
         char* filename = mj_rec_get_name();
               ^~~~~~~~
mj_rec.c:712:35: warning: implicit conversion from 'float' to 'double' to match other operand of binary expression [-Wdouble-promotion]
   double fps = ((double)FrameCount*1000.0)/(double)(StopWriteTime - StartWriteTime);
                                   ^
mj_rec.c:725:13: warning: unused variable 'rf' [-Wunused-variable]
   RIFFFILE* rf = (RIFFFILE*)mjpeg;
             ^~
At top level:
mj_rec.c:47:21: warning: 'NewFioTime' defined but not used [-Wunused-variable]
 static int FioTime, NewFioTime, OldFioTime;
                     ^~~~~~~~~~
mj_rec.c:42:13: warning: 'mjpeg_dbg_buf' defined but not used [-Wunused-variable]
 static char mjpeg_dbg_buf[255];
             ^~~~~~~~~~~~~
cc1: some warnings being treated as errors
../../Makefile.filerules:31: recipe for target 'mj_rec.o' failed
make: *** [mj_rec.o] Error 1
david@reddeercity:~/5D2-50D-Crop_Rec_4k_fix_raw.c_error_7-19-2020/magic-lantern_reddeercity_5d2-50d_4k-crop_rec/modules/mj_rec$
rec
 

I know there some other warning here , could they be related to the errors that stop the compile ?
I do know enough about this code to understand fully , can anyone offer so advice ?

mj_rec.c: In function 'mjpeg_video_rec_task':
mj_rec.c:479:16: error: implicit declaration of function 'get_ms_clock_value' [-Werror=implicit-function-declaration]
   OldFioTime = get_ms_clock_value();
                ^~~~~~~~~~~~~~~~~~

mj_rec.c:564:17: error: implicit declaration of function 'get_us_clock_value' [-Werror=implicit-function-declaration]
  NewFrameTime = get_us_clock_value();
                 ^~~~~~~~~~~~~~~~~~
here the source
https://bitbucket.org/reddeercity/crop_rec_5d2_50d/downloads/mj_rec.c
#17
I found something that i think may make the D4 cam user happy or at least the 5D2 & 50D users
A lone time ago , will at least in terms of camera reverse engineering .
back when there was branch "vxworks-dm-spy" mainly working off the 450d camera but other as well.
Developer "Ant123" wrote some code that is very useful to use and to other cams maybe D5 .
This code,  I've forgotten i had it been in my archives for 4-5 years , what is it you may ask ?
Its Mjpeg module , thou it was written for the 450d "Ant123" made a special built 5D2 build
I have the source code , but the problem is ( well it not big problems) i have get to work with the new
code base , it was written when we still use Raw 1st generation (###.raw) mainly and "MLV" was in 1st stages with mlv_lite. when there was only 14bit raw

So what are we talking about ? we should be able to record everything that RAW_record does
even crop_record special sizes , cause its base off the frame height, wide & frame rate
sames as raw recording modules does, so 3x1, 1x3 , hi-speed frame rate. not a preset HD like H264.mov
does.
Motion Jpeg is the file format which is 422 8bit color space in .AVI , really its the stream before H264 compression(4.2.0 color space) or the same as the HDMI stream (4.2.2 color space)
Its the same file format/codec as the canon 4k 1DC cine cam (they still demands have a very high used price)

https://bitbucket.org/Ant123/magic-lantern-450d/src/vxworks-dm-spy/modules/mj_rec/mj_rec.c
so here the code i found (its for the 450D but simular to my 5d2 code , you get the idea
I couldn't find the commit that i have d855737fc7cf
in the .hg_archival.txt file it show the last commit
repo: 4d0acc5c07929676956c3cb53c8173e198390d46
node: d855737fc7cf6c101b92bb6bea162bee7e4718f6
branch: vxworks-dm-spy
latesttag: ML-650D-Alpha1
latesttagdistance: 3757
changessincelatesttag: 6483
but i cannot found it on https://foss.heptapod.net/

this the README.rst
MJPEG video recorder
=========================

Records Motion JPEG AVI video.
In Live View mode press the shutter halfway to start recording.

Modes:

* Simple: press the shutter halfway to start recording.

:Author: Ant123
:License: GPL
:Summary: Records Motion JPEG AVI video.
here a bit of the code
struct AVIHeader
{
uint32_t dwMicroSecPerFrame;
uint32_t dwMaxBytesPerSec; //
uint32_t dwReserved1; // must be 0
uint32_t dwFlags; // 0 ?
uint32_t dwTotalFrames;
uint32_t dwInitialFrames; // here must be 0
uint32_t dwStreams; // number of streams
uint32_t dwSuggestedBufferSize;
uint32_t dwWidth; // width of frame
uint32_t dwHeight; // height of frame
uint32_t dwReserved[4]; // all must be 0
};

// size - 56
struct AVIStreamHeader
{
uint32_t fccType; // 'vids'
uint32_t fccHandler; // 'mjpg'
uint32_t dwFlags; // here 0
uint16_t wPriority; // here 0
uint16_t wLanguage; // here 0
uint32_t dwInitialFrames; // here 0
uint32_t dwScale; // dwMicroSecPerFrame
uint32_t dwRate; // 1000000
uint32_t dwStart; // here 0
uint32_t dwLength; // dwTotalFrames
uint32_t dwSuggestedBufferSize; //  size largest chunk in the stream
uint32_t dwQuality; // from 0 to 10000
uint32_t dwSampleSize; // here 0
struct // here all field zero
{
uint16_t left;
uint16_t top;
uint16_t right;
uint16_t bottom;
} rcFrame;
};

// size - 40
struct AVIStreamFormat
{
uint32_t biSize; // must be 40
int32_t  biWidth; // width of frame
int32_t  biHeight; // height of frame
uint16_t biPlanes; // here must be 1
uint16_t biBitCount; // here must be 24
uint32_t biCompression; // here 'MJPG' or 0x47504A4D
uint32_t biSizeImage; // size, in bytes, of the image (in D90_orig.avi 2764800)
int32_t  biXPelsPerMeter; // here 0
int32_t  biYPelsPerMeter; // here 0
uint32_t biClrUsed; // here 0
uint32_t biClrImportant; // here 0
};

struct AVIIndexChunk
{

so it has a avi writer , the hard part done :) 

First I'll do is start with 1st gen build and see if its successfully builds,
then i can try and implement in to the new code base.
   
#18
Quote from: SebastianC on July 04, 2024, 11:35:58 AMIt was fantastic! Never thought 5D2 still have more power. I used basic 5D2 raw vision which is pretty nice! I excited to test new features!
it not a new feature , just expanding on the crop_record 48p high frame rate preset
#19
General Help Q&A / Re: sacrificial fs700
July 12, 2024, 03:46:07 AM
This is interesting , i quickly look in to this i see it record 4k thru the the SDI & or HDMI
of course the simpleness way is a HDMI/SDI hard drive recorder .
Also depend on the model from my research you need a FS700R or a FS700U model
the "U" model has the 4k upgrade from sony (a software or a bios update)
where the FS700"R" model can be upgraded . if it just a FS700 then more then like no chance
of 4K. But if it shares the same architecture as the F5 ,it can be hack for 4k internal recording , http://extrashot.co.uk/howwedidit/ explain who its done very very simple .

so first step is to see what model of FS700 you have to work with , either the "R" or "U"
no other model.
#20
Made some headway on hi-speed 3x3 framerate (higher then 48fps that is)
I'm up 50.024 (stable, recordable) @ 1880x775 in 3x3 mode , I've got it up to 52.068 same resolution(not stable yet)
Finally I push to 54.01fps but then it lockup/froze needed a battery pull , I could have got it work but I didn't adjust
frame timer windows enough. If shrink the side width down from 1880 pixel to 1856 pixel & keep the vertical at 775 pixel
I should be able to reach 60fps. So that would be 1856x775 @ 60fps
This in 3x3 mode not 1.67 stretch(720p mode on D5 cams)  so cleaner image in 3x3

50.024 @ 1880x775 Stable


52.068fps @ 1880x775 recordable , but not stable yet


54.016fps @ 1880x775 (lockup/froze battery needed)

#21
Quote from: 2blackbar on July 02, 2024, 12:52:57 AMAny news on this? Would be very nice to have
nothing news worthy yet , lots of backend stuff basically I have to go line by line in the code.
could be a long time or a short time can't say right now. 
#22
Quote from: Skinny on June 07, 2024, 01:47:26 PMI'd say it will be really useful to get max FPS possible with h.264 (standard resolution) as well as 3x3 raw (16:9, 3:2, it doesn't need to be continuous)

3:2 h264 mode also would be great if possible, even if it is only 24 FPS
Raw i can do 60fps 3x3 1600x800 i do believe, h264 is around 40 fps i think, the think with H264
is it has a HD preset that is encodes to 1920x1080 , (you need to reduce resolution or a custom one)
That can't be change Yet (it could be with 422 Avi which the H264 gets it stream from) actually it start with the raw stream them goes to compressed 422 8bit .avi then H264 .
So the 40D (a D4 cam) has some success with avi compression (i have followed that development and hope to try and get it running on 5D2 someday ,
that's same compression as the canon 1DC 4k cinema cam.
#23
@An147 , dual iso is not as stable as its on 5D3 , anything over ISO 800(for low levels) & ISO 100 (for hi-light recovery) will give issue & beside that any ISO higher the 800 is digital push or pull not a true analog full clean ISO , even the 1/2 ISO changes e.g. ISO 150 or ISO 1200 (those are just pushed digitally) that being said , I only got good clean processing in MLVProducer
 https://www.magiclantern.fm/forum/index.php?msg=216415
https://sourceforge.net/projects/mlvproducer/files/mlvp.alpha.build3370.zip/download

Also remember there's aliasing & moiré still in 3X3 so dual ISO will magnify more.


#24
Camera-specific Development / Re: Canon 40D
June 12, 2024, 06:49:23 AM
No, I don't think so.
Really is there any projects that are dead ? or just haven't the time to get back to it.
Heder being working on the 7D(mark2) with great results , some day 40D will continue. 
#25
8221A> ShootCaptu:ff87fcc8:93:03: CreateJob end.
8226D> ShootCaptu:ff87ffa8:93:03: iso:0x50,tv:0x60,av:0x28,tp:159,po:100
822AC> ShootCaptu:ff87ffec:93:03: GetCaptureResources start.
822D4> ShootCaptu:000965bc:00:00: *** LockEngineResources(680404) x38 from ffa384f8:
8230D> ShootCaptu:00096678:00:00:      1)    50001 (?)
82332> ShootCaptu:00096678:00:00:      2)    50005 (?)
82353> ShootCaptu:00096678:00:00:      3)    50007 (?)
82374> ShootCaptu:00096678:00:00:      4)    50009 (?)
82397> ShootCaptu:00096678:00:00:      5)    5000e (?)
823B7> ShootCaptu:00096678:00:00:      6)    50011 (?)
823D7> ShootCaptu:00096678:00:00:      7)    50019 (?)
823F7> ShootCaptu:00096678:00:00:      8)    5001b (?)
82419> ShootCaptu:00096678:00:00:      9)    5001e (?)
8243B> ShootCaptu:00096678:00:00:     10)    50013 (?)
8245C> ShootCaptu:00096678:00:00:     11)    50020 (?)
8247D> ShootCaptu:00096678:00:00:     12)    50021 (?)
8249F> ShootCaptu:00096678:00:00:     13)    70000 (?)
824C1> ShootCaptu:00096678:00:00:     14)    f0000 (?)
824E2> ShootCaptu:00096678:00:00:     15)    b0000 (?)
82505> ShootCaptu:00096678:00:00:     16)   200002 (?)
82528> ShootCaptu:00096678:00:00:     17)   140000 (?)
8254C> ShootCaptu:00096678:00:00:     18)   120000 (?)
82570> ShootCaptu:00096678:00:00:     19)   130009 (?)
82593> ShootCaptu:00096678:00:00:     20)   13000a (?)
825B9> ShootCaptu:00096678:00:00:     21)   13000b (?)
825DB> ShootCaptu:00096678:00:00:     22)   13000d (?)
825FE> ShootCaptu:00096678:00:00:     23)   13000e (?)
82621> ShootCaptu:00096678:00:00:     24)   13000f (?)
82645> ShootCaptu:00096678:00:00:     25)   130016 (?)
82669> ShootCaptu:00096678:00:00:     26)   22001b (?)
82695> ShootCaptu:00096678:00:00:     27)        0 (write channel 0x0)
826BC> ShootCaptu:00096678:00:00:     28)        1 (write channel 0x1)
826E0> ShootCaptu:00096678:00:00:     29)        2 (write channel 0x2)
82704> ShootCaptu:00096678:00:00:     30)        6 (write channel 0x6)
82728> ShootCaptu:00096678:00:00:     31)    10000 (read channel 0x8)
82750> ShootCaptu:00096678:00:00:     32)    10001 (read channel 0x9)
82779> ShootCaptu:00096678:00:00:     33)    20000 (write connection 0x0)
827A4> ShootCaptu:00096678:00:00:     34)    20002 (write connection 0x2)
827CD> ShootCaptu:00096678:00:00:     35)    20012 (write connection 0x12)
827F9> ShootCaptu:00096678:00:00:     36)    2001c (write connection 0x1c)
82822> ShootCaptu:00096678:00:00:     37)    30008 (read connection 0x8)
8284B> ShootCaptu:00096678:00:00:     38)    3000f (read connection 0xf)

D9805> ShootCaptu:000965bc:00:00: *** UnLockEngineResources(680a68) x1 from ffa384cc:
D9846> ShootCaptu:00096678:00:00:      1)    40000 (?)
D989B> ShootCaptu:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
D98DA> ShootCaptu:000965bc:00:00: *** UnLockEngineResources(680404) x38 from ffa38524:
D9911> ShootCaptu:00096678:00:00:      1)    50001 (?)
D993B> ShootCaptu:00096678:00:00:      2)    50005 (?)
D995B> ShootCaptu:00096678:00:00:      3)    50007 (?)
D997C> ShootCaptu:00096678:00:00:      4)    50009 (?)
D99A0> ShootCaptu:00096678:00:00:      5)    5000e (?)
D99C1> ShootCaptu:00096678:00:00:      6)    50011 (?)
D99E2> ShootCaptu:00096678:00:00:      7)    50019 (?)
D9A02> ShootCaptu:00096678:00:00:      8)    5001b (?)
D9A25> ShootCaptu:00096678:00:00:      9)    5001e (?)
D9A45> ShootCaptu:00096678:00:00:     10)    50013 (?)
D9A65> ShootCaptu:00096678:00:00:     11)    50020 (?)
D9A87> ShootCaptu:00096678:00:00:     12)    50021 (?)
D9AA8> ShootCaptu:00096678:00:00:     13)    70000 (?)
D9ACA> ShootCaptu:00096678:00:00:     14)    f0000 (?)
D9AEC> ShootCaptu:00096678:00:00:     15)    b0000 (?)
D9B0F> ShootCaptu:00096678:00:00:     16)   200002 (?)
D9B36> ShootCaptu:00096678:00:00:     17)   140000 (?)
D9B57> ShootCaptu:00096678:00:00:     18)   120000 (?)
D9B7D> ShootCaptu:00096678:00:00:     19)   130009 (?)
D9B9F> ShootCaptu:00096678:00:00:     20)   13000a (?)
D9BC1> ShootCaptu:00096678:00:00:     21)   13000b (?)
D9BE4> ShootCaptu:00096678:00:00:     22)   13000d (?)
D9C06> ShootCaptu:00096678:00:00:     23)   13000e (?)
D9C2A> ShootCaptu:00096678:00:00:     24)   13000f (?)
D9C4D> ShootCaptu:00096678:00:00:     25)   130016 (?)
D9C71> ShootCaptu:00096678:00:00:     26)   22001b (?)
D9C9D> ShootCaptu:00096678:00:00:     27)        0 (write channel 0x0)
D9CC5> ShootCaptu:00096678:00:00:     28)        1 (write channel 0x1)
D9CED> ShootCaptu:00096678:00:00:     29)        2 (write channel 0x2)
D9D15> ShootCaptu:00096678:00:00:     30)        6 (write channel 0x6)
D9D3B> ShootCaptu:00096678:00:00:     31)    10000 (read channel 0x8)
D9D65> ShootCaptu:00096678:00:00:     32)    10001 (read channel 0x9)
D9D8E> ShootCaptu:00096678:00:00:     33)    20000 (write connection 0x0)
D9DB9> ShootCaptu:00096678:00:00:     34)    20002 (write connection 0x2)
D9DE2> ShootCaptu:00096678:00:00:     35)    20012 (write connection 0x12)
D9E0E> ShootCaptu:00096678:00:00:     36)    2001c (write connection 0x1c)
D9E36> ShootCaptu:00096678:00:00:     37)    30008 (read connection 0x8)
D9E5E> ShootCaptu:00096678:00:00:     38)    3000f (read connection 0xf)

The above 2 pieces or log file , i think is needed to get lossless compression working on 5D2
the below piece of log file is related to all D4 cams but i suspect somthing is needed from the above
log file , as previous lossless compression test (silent picture) always lockup during the saving routines. Like the its not unlocking or locking the (ProcessTwoInTwoOutJpegPath) that the D4 version
of lossless , plus I think D5 cam use 4 in & 4 out streams maybe just the 5D3 , the D4 use 2 in & 2 out . In the end there some missing resources or the code structure is wrong for d4 (wouldn't be the first time i had to change so D5 code to work in D4 cams  :) 
1B0BF> FrontShtDe:ffa590d4:16:03: [TTJ] STOP WR1:0x3615254 WR2:0x1ad28248
1B10A> FrontShtDe:ffa59100:16:03: [TTJ] STOP RD1:0x124cf564 RD2:0x124d1864
1B185> FrontShtDe:000965bc:00:00: *** UnLockEngineResources(72bed4) x17 from ffa5905c:
1B1D6> FrontShtDe:00096678:00:00:      1)    10002 (read channel 0xa)
1B205> FrontShtDe:00096678:00:00:      2)        3 (write channel 0x3)
1B22C> FrontShtDe:00096678:00:00:      3)        4 (write channel 0x4)
1B252> FrontShtDe:00096678:00:00:      4)    30000 (read connection 0x0)
1B27D> FrontShtDe:00096678:00:00:      5)    20005 (write connection 0x5)
1B2A6> FrontShtDe:00096678:00:00:      6)    20016 (write connection 0x16)
1B2C9> FrontShtDe:00096678:00:00:      7)    50003 (?)
1B2EA> FrontShtDe:00096678:00:00:      8)    5000d (?)
1B30B> FrontShtDe:00096678:00:00:      9)    5000f (?)
1B32D> FrontShtDe:00096678:00:00:     10)    5001a (?)
1B350> FrontShtDe:00096678:00:00:     11)    80000 (?)
1B39E> FrontShtDe:00096678:00:00:     12)    90000 (?)
1B3CC> FrontShtDe:00096678:00:00:     13)    a0000 (?)
1B3F3> FrontShtDe:00096678:00:00:     14)   160000 (?)
1B419> FrontShtDe:00096678:00:00:     15)   130003 (?)
1B43C> FrontShtDe:00096678:00:00:     16)   130004 (?)
1B460> FrontShtDe:00096678:00:00:     17)   130005 (?)
1B4B9> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B503> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B588> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B5CA> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B5FE> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B62E> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B65F> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B68F> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B6BE> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B6F0> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B71E> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B74A> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B777> FrontShtDe:ff9a77d0:00:01: [CLKSAVER] ��ClockSave Out��
1B7CA> FrontShtDe:ff888f10:96:05: ProcessTwoInTwoOutJpegPath(R) End(5742)
This part of the resources i have used in my lossless compression test a few years ago , It did compress the image
and that's it , so that kind of telling me its not unlocking after locking resources.