Magic Lantern Forum
Developing Magic Lantern => General Development => Topic started by: theBilalFakhouri on April 07, 2022, 06:20:22 AM
-
Hi, is this April 1st?
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2F9TDLZY0%2F700-D-Live-View-Write.jpg&hash=396e8417e2d40e3dabbf5e0ecd030fae) (https://ibb.co/DCJyrKF) (https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FpRRcyXd%2FApril-1st.jpg&hash=2a598d7cade0138c4e3a6bc889271ce8) (https://ibb.co/CMMg20Q)
Last week I was looking for ways to gain extra write speed while RAW recording, e.g by disabling Canon tasks in background or something like that . .
That idea lives! . . managed to gain ~13 MB/s write speed improvement in LiveView, all RAW video modes are benefited, the following benchmarks in 1080p24 mode:
1- 700D (with 240MHz SD overclock):
Before (Default, no hacks): After (with new hacks):
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FsyYYfF3%2FDefault.png&hash=ddc6d5178057f9f98ec68a6dd4bebf24) (https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2Fd5VSNr5%2Fwith-hacks.png&hash=ce0c49572cd4b578088e69dc0a317350)
-Combining the new hacks with the "Small hacks" from RAW video:
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FpRFGX5g%2Fall-hacks.png&hash=c9be1ae614e2d7208733707ec047cc14)
-82.8 MB/s write speed in LiveView 8)
Demo
:
-Some results:
-2560x1440 1:1 16:9 Continuous! (@ 23.976, 10-bit lossless)
-1736x2214 1x3 2.35:1 Continuous! (@ 23.976, 10-bit lossless)
-2880x1226 1:1 2.35:1 Continuous! (@ 23.976, 10-bit lossless)
-You can definitely record longer in 3K 3072x1308 1:1 2.35:1 preset (@ 23.976, 10-bit lossless)
-High frame rate modes can be Continuous! or "You can definitely record longer".
-feel free to test other modes, with different bit-depths, and don't forget to share the result.
-The Details:
I was trying to find a clean way to see LiveView activity how it start and how it stop, what processes are being activated, how we can deactivate some of unnecessary processes in a clean way (by calling Canon functions), so I got an idea to capture DebugMsg log, between PauseLiveView and ResumeLiveView functions, once with MMIO and once without them, I got interesting sequence of how LiveView processes are being deactivated:
32.309.545 run_test:0008b598:00:00: Pause LiveView
32.309.782 MainCtrl:ff0ceef0:9c:01: ID:1(24)
32.309.857 MainCtrl:ff0ceefc:9c:03: Request LV_ACTION : (1)
32.310.068 MainCtrl:ff0ceef0:9c:01: ID:80050022(25)
32.310.125 MainCtrl:ff1476cc:9c:03: PROP_LV_ACTION : LV_STOP
32.310.228 PropMgr:ff2a6a5c:33:01: PropCBR camctrl:0x80050022,0x1
32.310.254 PropMgr:ff0ff82c:33:01: PD_CheckAudioLevelStart
32.310.285 PropMgr:ff0fecb4:33:01: SendPipeEvent [0][0][88]
32.310.354 PropMgr:ff1c6f78:83:01: changeCBR PropID(0x80050022)Parameter(1)Size(4)
32.310.787 PropMgr:ff10e818:14:03: alvChangeAckCBR : PROP_MOVIE_SOUND_RECORD[0x205000e]
32.310.837 PropMgr:ff10e518:14:03: _ALV_SetALCMode : Change ALCMode[2->1]
32.310.894 PropMgr:ff0e3d00:2f:05: mvrChangeAckCBR : Sound Auto(C=2,R=48000,B=16)
32.310.934 PropMgr:ff0ff0c8:33:01: ptpPropChangeEvCBR[205000e][4][2]
32.310.976 PropMgr:ff0fecb4:33:01: SendPipeEvent [0][0][9]
32.311.044 PropMgr:ff1c6f78:83:01: changeCBR PropID(0x205000e)Parameter(2)Size(4)
32.311.185 Gmt:ff181a78:9a:01: gmtProperty ID=0x80050022(0x1)
32.311.279 Gmt:ff19dfe8:9a:03: [LVREC]Gmt::CurrentState:0, Event:8
32.311.297 Gmt:ff19e690:9a:03: [LVREC] gmtIgnore
32.311.322 Gmt:ff180f8c:9a:03: gmtConductorStop
32.311.404 Gmt:ff1771b8:a9:03: evfComAct(12)
32.311.429 Gmt:ff17746c:a9:03: COM_ACT_LV_SUSPEND
32.311.516 Evf:ff179ce4:a9:03: evfStop
32.311.611 Evf:ff4ee868:a9:01: [VRAM]vram_SetSenserDriveParameter(105, 1212, 0 1)
32.311.633 Evf:ff4ee888:a9:01: [VRAM]vram_SetSenserDriveParameter(0, 0, 0 0)
32.311.647 Evf:ff3810e0:ae:03: SDRV_StopDevice
32.311.681 Evf:ff380988:ae:03: UnregisterHDInterruptCBR
32.311.704 Evf:ff3809c8:ae:01: sdrv_unregisterHdInterruptCBR[1]
32.311.740 Evf:ff380988:ae:03: UnregisterHDInterruptCBR
32.311.755 Evf:ff3809c8:ae:01: sdrv_unregisterHdInterruptCBR[0]
32.311.840 AeWb:ff263690:98:03: [AEWB] aewbLvComAct(12):ActionType
32.311.895 AeWb:ff261f58:98:03: [AEWB] aewbSuspend
32.311.919 AeWb:ff2715ac:b0:03: [AF] AfCtrl_Act_Suspend
32.312.004 AeWb:ff272b70:b5:03: [CLRCALC] CLR_CALC_Stop
32.312.059 AeWb:ff380784:ae:03: UnregisterVDInterruptCBR
32.312.193 LVFACE:ff17d650:aa:03: lvfaceEnd
32.312.547 LVFACE:ff2c6edc:00:00: *** SetEDmac(0xc, 0x0, 0x0, 0x0)
32.312.806 Gmt:ff0d5a9c:9a:01: Event 4 Result State 6->7
32.312.847 Gmt:ff19c2c8:ab:03: [GRPCTR] LVGRAPHIC_CTRL_PermitPowerLockForcibly[0][0]
32.312.873 Gmt:ff19b840:ab:03: [GRPCTR] graphic_ctrl_PermitPowerLock[0][0]
32.312.935 Gmt:ff0d5a9c:9a:01: Event 19 Result State 6->7 ID 0x80050022(1)
32.312.988 Gmt:ff18023c:9a:03: gmtInactivateConductor:0x7 0x10
32.313.016 Gmt:ff0d5a9c:9a:01: Event 6 Result State 7->7
32.313.055 Gmt:ff18023c:9a:03: gmtInactivateConductor:0x5 0x2
32.313.076 Gmt:ff0d5a9c:9a:01: Event 6 Result State 7->7
32.313.116 Gmt:ff18023c:9a:03: gmtInactivateConductor:0x1 0x4
32.313.140 Gmt:ff0d5a9c:9a:01: Event 6 Result State 7->7
32.313.247 GuiMainTas:00002928:00:00: >>> INT-6Ah FF56FB28(00000000)
32.313.393 GuiMainTas:00002928:00:00: <<< INT-6Ah done
32.313.445 Evf:ff179d5c:a9:03: evfStandby
32.313.483 Evf:ff17ac14:9b:01: CancelDeliverStage
32.313.522 Evf:ff17bab0:9b:01: CancelJpegStage
32.313.568 Evf:ff17cef8:9b:01: [CFIL] CancelCFilterStage 0xff0d49c8 0x0
32.313.647 Evf:ff19d588:ad:01: Cartridge Cancel[0]
32.313.669 Evf:ff4fb0c0:ad:01: RecStandby_x1_CancelPreproPath
32.313.702 Evf:ff4faf9c:ad:01: RecStandby_x1_StopPreproPath[0][dc70000]
32.313.742 Evf:ff382808:98:01: [RSHD] RSHD_DRV_Stop
32.313.782 Evf:ff4fafe4:00:00: >>> INT-5Eh EDMAC#9 00011144(00000009)
32.313.825 Evf:ff4fafe4:00:00: addr 0217A840, ptr 0217B608, size (please load edmac.mo), flags 40010000
32.313.853 **INT-5Eh*:00000564:ad:01: ReadEDmacHivshdAbortCBR
32.313.866 Evf:ff4fafe4:00:00: <<< INT-5Eh done
32.313.894 Evf:ff0c1118:00:00: >>> INT-5Dh EDMAC#8 00011144(00000008)
32.313.924 Evf:ff0c1118:00:00: addr 020F61EC, ptr 02109680, size (please load edmac.mo), flags 40010000
32.313.945 **INT-5Dh*:00000564:ad:01: ReadEDmacDefCorreAbortCBR
32.313.956 Evf:ff0c1118:00:00: <<< INT-5Dh done
32.313.995 Evf:ff0c1118:00:00: >>> INT-5Ah EDMAC#2 00010F90(00000002)
32.314.022 Evf:ff0c1118:00:00: addr 0BDE7800, ptr 0BDE7800, size (please load edmac.mo), flags 20000000
32.314.042 **INT-5Ah*:00000564:ad:01: WriteEDmacVramAbortCBR
32.314.053 Evf:ff0c1118:00:00: <<< INT-5Ah done
32.314.070 Evf:ff4fb884:ad:01: [PATH] RecStandby_x1_StopVramPath
32.314.102 Evf:ff3847a4:ad:01: [DEVDRV] LVDEV_DRV_StopCommon
32.314.211 Evf:ff37b290:ad:01: HistLCG_CancelPath
32.314.264 Evf:ff0c1118:00:00: >>> INT-59h EDMAC#1 00010F90(00000001)
32.314.299 Evf:ff0c1118:00:00: addr 04000080, ptr 04000080, size (please load edmac.mo), flags 20000000
32.314.323 **INT-59h*:00000564:ad:01: WriteEDmacYuvAbortCBR
32.314.335 Evf:ff0c1118:00:00: <<< INT-59h done
32.314.386 Evf:ff0c1118:00:00: >>> INT-F9h EDMAC#16 00010F90(00000010)
32.314.416 Evf:ff0c1118:00:00: addr 0DC70000, ptr 0DC70000, size (please load edmac.mo), flags 00000080
32.314.435 **INT-F9h*:00000564:ad:01: WriteEDmacFenYuvAbortCBR
32.314.446 Evf:ff0c1118:00:00: <<< INT-F9h done
32.314.468 Evf:ff3800d8:ad:01: WbInteg_CancelPath
32.314.486 Evf:ff4fe54c:98:01: [FST] FSTPAS_DRV_Stop
32.314.508 Evf:ff4fed3c:98:01: [WBITG] WBINTEG_DRV_Stop
32.314.578 Evf:ff4fe3bc:98:01: [AEITG] AEINTEG_DRV_Stop
32.314.607 Evf:ff0c1118:00:00: >>> INT-6Dh EDMAC#5 00010F90(00000005)
32.314.638 Evf:ff0c1118:00:00: addr 0D9C1E00, ptr 0D9C1E00, size (please load edmac.mo), flags 20000040
32.314.661 Evf:ff0c1118:00:00: <<< INT-6Dh done
32.314.692 Evf:ff37be7c:ad:01: ObInteg_CancelPath
32.314.715 Evf:ff37f010:ad:01: Af_CancelPath
32.314.737 Evf:ff0c1118:00:00: >>> INT-83h EDMAC#17 00010F90(00000011)
32.314.764 Evf:ff0c1118:00:00: addr 007543F8, ptr 007543F8, size (please load edmac.mo), flags 20000080
32.314.786 **INT-83h*:00000564:ad:01: AfWrDmacAbortCBR
32.314.798 Evf:ff0c1118:00:00: <<< INT-83h done
32.314.898 Evf:ff4ee868:a9:01: [VRAM]vram_SetSenserDriveParameter(105, 1212, 0 1)
32.314.919 Evf:ff4ee888:a9:01: [VRAM]vram_SetSenserDriveParameter(0, 0, 0 0)
32.314.936 Evf:ff381108:ae:03: SDRV_StanbyDevice
32.314.951 Evf:ff3803b0:ae:01: sdrv_SetSenserDriveParameter
32.314.994 Evf:ff56ea34:91:01: SetLvTgNextState[10] 2527
32.315.032 Evf:00017928:91:01: [REG] @@@@@@@@@@@@ Start ADTG[CS:2:404528c4]
32.315.061 Evf:000179b0:91:01: [REG] ADTG:[0x80000000]
32.315.083 Evf:000179f8:91:01: [REG] ADTG:[01050000] <----- Excel Tab Number
32.315.093 Evf:00017a14:91:01: [REG] Total:2
32.315.122 Evf:00017928:91:01: [REG] @@@@@@@@@@@@ Start ADTG[CS:2:40453398]
32.315.149 Evf:000179b0:91:01: [REG] ADTG:[0x8860000c]
32.315.173 Evf:000179b0:91:01: [REG] ADTG:[0x88b00000]
32.315.195 Evf:000179f8:91:01: [REG] ADTG:[05100000] <----- Excel Tab Number
32.315.205 Evf:00017a14:91:01: [REG] Total:3
32.315.317 Epp:ff17afc8:9b:01: deliverCancelJob:0
32.315.348 Epp:ff0d49e4:9b:03: Epp_CancelCompleteCBR (0x00000008)
32.315.399 Epp:ff17c16c:9b:01: jpegCancelJob:0
32.315.427 Epp:ff17c1f0:9b:01: Alloc[0]Shrink[0]Free[0]JpegCnt[0]
32.315.450 Epp:ff17c20c:9b:01: ###Cmp[-15238532, Cnt=[0]
32.315.473 Epp:ff177a98:a9:03: evfCompleteTransferYuvCBR 0
32.315.494 Epp:ff0d49e4:9b:03: Epp_CancelCompleteCBR (0x00000020)
32.315.546 Epp:ff37352c:9b:01: [CFIL] roughMonoCancel 0xff0d49c8
32.315.580 Epp:ff0d49e4:9b:03: Epp_CancelCompleteCBR (0x00000010)
32.315.606 Epp:ff177988:a9:03: evfJobCancelCompleteCBR
32.315.663 Epp:ff0d4a28:9b:03: Cancel_Complete!!
32.315.685 Epp:ff0d4ad4:9b:03: Select NOMAL
32.315.824 CLR_CALC:ff275fdc:b5:03: [CLRCALC] ClrCalc_Stop
32.316.193 CtrlSrv:ff39bb28:83:03: MainEventHandler PROP_LV_ACTION(1)
32.316.223 CtrlSrv:ff39a214:83:03: MainEventHandler PROP_LV_STOP
32.316.524 CtrlSrv:ff3bd9d8:c0:03: CtrlSrv GuiClearBackImageWithoutRefresh(2783) DisplayType:0
32.316.589 CtrlSrv:ff52c1f0:83:03: StopLiveViewApp(0x8d2ce4)
32.316.604 CtrlSrv:ff695a20:83:03: StopLiveViewErrorApp
32.316.630 CtrlSrv:ff6d8664:83:03: StopLiveViewUnaviApp(0x0)
32.316.649 CtrlSrv:ff697218:83:03: StopLiveViewIsoApp(0x0)
32.316.663 CtrlSrv:ff698848:83:03: StopLiveViewQualityApp
32.316.679 CtrlSrv:ff6deba8:83:03: StopLiveViewEfApp
32.316.697 CtrlSrv:ff6e6bf0:83:03: StopLiveViewShutterApp
32.316.804 CtrlSrv:00002780:00:00: >>> INT-6Ah FF56FB28(00000000)
32.316.950 CtrlSrv:00002780:00:00: <<< INT-6Ah done
32.317.017 Evf:ff179dd4:a9:03: evfEnd[FrameNo:56]
32.317.062 Evf:ff380a90:ae:03: UnregisterHeadErrorInterruptCBR
32.317.099 Evf:ff3804fc:ae:03: UnregisterVDInterruptHigherPriCBR
32.317.172 Evf:ff4ee868:a9:01: [VRAM]vram_SetSenserDriveParameter(105, 1212, 0 1)
32.317.195 Evf:ff4ee888:a9:01: [VRAM]vram_SetSenserDriveParameter(0, 0, 0 0)
32.317.212 Evf:ff381188:ae:03: SDRV_ShutdownDevice
32.317.226 Evf:ff3803b0:ae:01: sdrv_SetSenserDriveParameter
32.317.275 Evf:ff56ea34:91:01: SetLvTgNextState[14] 2527
32.317.323 Evf:00017928:91:01: [REG] @@@@@@@@@@@@ Start ADTG[CS:2:40452980]
32.317.354 Evf:000179b0:91:01: [REG] ADTG:[0x81700051]
32.317.377 Evf:000179b0:91:01: [REG] ADTG:[0x81760051]
32.317.398 Evf:000179f8:91:01: [REG] ADTG:[01090000] <----- Excel Tab Number
32.317.409 Evf:00017a14:91:01: [REG] Total:3
32.317.438 Evf:00017928:91:01: [REG] @@@@@@@@@@@@ Start ADTG[CS:2:404534a8]
32.317.462 Evf:000179b0:91:01: [REG] ADTG:[0x00303ffd]
32.317.480 Evf:000179b0:91:01: [REG] ADTG:[0x00082809]
32.317.502 Evf:000179f8:91:01: [REG] ADTG:[02060000] <----- Excel Tab Number
32.317.513 Evf:00017a14:91:01: [REG] Total:3
32.317.538 Evf:00017928:91:01: [REG] @@@@@@@@@@@@ Start ADTG[CS:2:40453320]
32.317.565 Evf:000179b0:91:01: [REG] ADTG:[0x89000000]
32.317.588 Evf:000179b0:91:01: [REG] ADTG:[0x88120000]
32.317.610 Evf:000179b0:91:01: [REG] ADTG:[0x89080000]
32.317.631 Evf:000179f8:91:01: [REG] ADTG:[05050000] <----- Excel Tab Number
32.317.641 Evf:00017a14:91:01: [REG] Total:4
32.317.653 Evf:ff3f50a0:92:03: PowerDownLvds
32.317.694 Evf:ff56f6ac:91:05: ImagePowerOff
32.317.768 Evf:ff19d4a0:ad:01: Cartridge Clear[0]
32.318.458 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.318.512 Evf:ff37b248:ad:01: HistLCG_ClearPath
32.318.623 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.318.654 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.318.694 Evf:ff4fb9fc:ad:01: RecStandby_x1_ClearVramPath
32.318.718 Evf:ff38401c:ad:01: [DEVDRV] LVDEV_DRV_End
32.318.819 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.318.848 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.318.871 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.318.891 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.318.919 Evf:000c6438:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.319.002 Evf:000c6438:00:00: <<< INT-0Ah done
32.319.083 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.319.152 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.319.235 Evf:ff2c6edc:00:00: *** SetEDmac(0x2, 0x0, 0x0, 0x0)
32.319.380 Evf:ff2c6edc:00:00: *** SetEDmac(0x1, 0x0, 0x0, 0x0)
32.319.576 Evf:ff2c6edc:00:00: *** SetEDmac(0x10, 0x0, 0x0, 0x0)
32.319.637 Evf:ff4fb024:ad:01: RecStandby_x1_ClearPreproPath
32.319.749 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.319.785 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.319.825 Evf:ff382790:98:01: [RSHD] RSHD_DRV_End
32.319.966 Evf:ff2c6edc:00:00: *** SetEDmac(0x9, 0x0, 0x0, 0x0)
32.320.022 Evf:ff2c6edc:00:00: *** SetEDmac(0x8, 0x0, 0x0, 0x0)
32.320.063 Evf:ff2c6edc:00:00: *** SetEDmac(0x12, 0x0, 0x0, 0x0)
32.320.113 Evf:ff380080:ad:01: WbInteg_ClearPath
32.320.193 Evf:ff2c6edc:00:00: *** SetEDmac(0x5, 0x0, 0x0, 0x0)
32.320.270 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.320.320 Evf:ff4fe4b4:98:01: [FST] FSTPAS_DRV_End
32.320.342 Evf:ff4fec94:98:01: [WBITG] WBINTEG_DRV_End
32.320.359 Evf:ff4fe34c:98:01: [AEITG] AEINTEG_DRV_End
32.320.384 Evf:ff37be34:ad:01: ObInteg_ClearPath
32.320.463 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.320.510 Evf:ff37edd4:ad:01: Af_ClearPath
32.320.612 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.320.662 Evf:ff2c6edc:00:00: *** SetEDmac(0x11, 0x0, 0x0, 0x0)
32.320.750 Evf:ff19cda4:ad:03: PathEnd Start
32.320.765 Evf:ff36e014:ad:03: PathEnd End
32.320.912 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.321.006 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.321.077 Evf:ff0d6478:b9:07: LVICV_ReleaseResource
32.321.173 Evf:ff0c1118:00:00: >>> INT-8Bh EDMAC#24 00011144(00000018)
32.321.213 Evf:ff0c1118:00:00: addr 0159E930, ptr 0159FE80, size (please load edmac.mo), flags 40020000
32.321.244 Evf:ff0c1118:00:00: <<< INT-8Bh done
32.321.284 Evf:ff0c1118:00:00: >>> INT-58h EDMAC#0 00010F90(00000000)
32.321.314 Evf:ff0c1118:00:00: addr 01FA72B0, ptr 01FAE77C, size (please load edmac.mo), flags 00000000
32.321.335 Evf:ff0c1118:00:00: <<< INT-58h done
32.321.467 Evf:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.321.529 Evf:ff2c6edc:00:00: *** SetEDmac(0x18, 0x0, 0x0, 0x0)
32.321.589 Evf:ff2c6edc:00:00: *** SetEDmac(0x0, 0x0, 0x0, 0x0)
32.321.678 Evf:ff138e74:00:01: [PM] EnablePowerSave (Counter = 1)
32.321.943 LVICV:ff2c6edc:00:00: *** SetEDmac(0x2a, 0x0, 0x0, 0x0)
32.322.008 LVICV:ff2c6edc:00:00: *** SetEDmac(0x2b, 0x0, 0x0, 0x0)
32.322.100 LVICV:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.322.160 LVICV:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.322.185 LVICV:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.322.223 LVICV:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.322.308 LVICV:ff2c5d78:00:01: [CLKSAVER] پڑClockSave Outپڑ
32.322.358 LVICV:ff1a27d4:b9:03: ===== ResUnLock (Tracking) ====
32.322.502 Gmt:ff18023c:9a:03: gmtInactivateConductor:0x0 0x1
32.322.550 Gmt:ff1771b8:a9:03: evfComAct(22)
32.322.577 Gmt:ff177628:a9:03: COM_ACT_LV_RELEASE_VRAM 1
32.322.679 AeWb:ff263690:98:03: [AEWB] aewbLvComAct(22):ActionType
32.322.789 Gmt:ff0eb22c:80:03: SRM_FreeMemoryResourceForLiveViewYuv 0x44000064
32.322.863 RscMgr:ff0e5e2c:80:02: srmEventDispatch: Current = 0, dwEventID = 1, dwParam = 12 S
32.322.958 RscMgr:ff210844:80:03: ---- MODE[0 0 0]
32.323.043 RscMgr:ff20c38c:80:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)
32.323.122 RscMgr:ff21df38:80:05: srmFreeLiveView 0x44000064 0x44000064
32.323.155 RscMgr:ff215118:80:01: ###### VirtualFreeMemoryToShootMemoryObject 0x11C968
32.323.191 RscMgr:ff214dcc:80:01: VirtualAllocFreeMemory 0x11C968 0x6CA770 0x0
32.323.227 RscMgr:ff214e5c:80:01: ###### ChunkSize 32653324
32.323.258 RscMgr:ff214e88:80:01: ###### VIRTUAL_FREE pMemoryUnit->VirtualFreeSize[0] 32653328
32.323.287 RscMgr:ff214eb4:80:01: ###### +pMemoryObject->Virtual1stFreeSize 131514304
32.323.307 RscMgr:ff215084:80:01: ###### +pMemoryObject->Virtual2ndFreeSize 0
32.323.358 RscMgr:ff2144d8:80:01: FreeMemoryToShootMemoryObject 131514304 32653312 0x11C968
32.323.380 RscMgr:ff2144ec:80:01: ###### FreeMemoryToShootMemoryObject 0x11C968
32.323.500 RscMgr:ff21dfcc:80:01: FreeLV 12 11C968 0 3
32.323.542 RscMgr:ff21dff4:80:03: #LiveView YUV ADDR Free 0x44000064
32.323.607 RscMgr:ff210844:80:03: ---- MODE[0 0 0]
32.323.684 RscMgr:ff20c38c:80:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)
32.323.779 RscMgr:ff210844:80:03: ---- MODE[0 0 0]
32.324.023 RscMgr:ff20c38c:80:03: RealClearBusy(0x2100) 0x0->0x0,0x0(0x0)
32.324.082 RscMgr:ff20c38c:80:03: RealClearBusy(0x1) 0x0->0x0,0x0(0x0)
32.324.151 RscMgr:ff0e6034:80:02: srmEventDispatch: Current = 0, dwEventID = 1, dwParam = 12 E
32.324.210 Gmt:ff3806c0:ae:03: UnregisterVDInterruptMiddlePriCBR
32.324.232 Gmt:ff380784:ae:03: UnregisterVDInterruptCBR
32.324.296 Gmt:ff1771b8:a9:03: evfComAct(21)
32.324.381 AeWb:ff263690:98:03: [AEWB] aewbLvComAct(21):ActionType
32.324.490 Gmt:ff376e94:9a:03: libres_FreeMemorySsDevelopCBR
32.324.520 Gmt:ff235db8:97:05: [MNAV] MEMNAVI_SetMemoryMap: 1
32.324.568 Gmt:ff19c2c8:ab:03: [GRPCTR] LVGRAPHIC_CTRL_PermitPowerLockForcibly[0][0]
32.324.592 Gmt:ff19b840:ab:03: [GRPCTR] graphic_ctrl_PermitPowerLock[0][0]
32.324.619 Gmt:ff19c56c:ab:03: [GRPCTR] LVGRAPHIC_CTRL_MuteOffForcibly[0][0]
32.324.655 Gmt:ff0d5a9c:9a:01: Event 6 Result State 7->8
32.324.704 Gmt:ff1858a8:9a:03: gmtReleaseVram state:8
32.324.721 Gmt:ff37647c:9a:03: GMTLIB_RESOURCE_RequestFreeMemoryVram
32.324.766 Gmt:ff0e9a80:80:03: SRM_FreeMemoryResourceForImgVram 154 3
32.324.840 RscMgr:ff0e5e2c:80:02: srmEventDispatch: Current = 0, dwEventID = 1, dwParam = 17 S
32.324.895 RscMgr:ff21e234:80:03: Free ImgVram : Normal
32.324.921 RscMgr:ff21e258:80:03: ImgVram Before 154 154 154
32.324.947 RscMgr:ff3763fc:9a:03: libres_FreeMemoryVramCBR
32.324.965 RscMgr:ff21e2b4:80:03: srmFreeImgVram 154 3 3
32.325.005 RscMgr:ff21e494:80:03: ImgVram After -1 -1 -1
32.325.057 RscMgr:ff0e6034:80:02: srmEventDispatch: Current = 0, dwEventID = 1, dwParam = 17 E
32.325.115 Gmt:ff0d5a9c:9a:01: Event 27 Result State 8->8
32.325.177 Gmt:ff17ff24:9a:03: gmtReleaseResource:0x0(0x4000)
32.325.205 Gmt:ff1941f4:9a:03: [WAKU] gmtStopWaku (state:7)
32.325.292 Gmt:ff189de4:9a:01: [WAKU] Event 18 Result State 7->7
32.325.331 Gmt:ff0d5a9c:9a:01: Event 5 Result State 8->9
32.325.371 Gmt:ff181118:9a:03: gmtStop:1
32.325.414 Gmt:ff0d5a9c:9a:01: Event 7 Result State 9->9
32.325.964 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.326.085 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.328.913 CtrlSrv:0001c388:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.328.974 CtrlSrv:0001c388:00:00: <<< INT-0Ah done
32.330.547 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2632 dword=342
32.331.848 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.333.119 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.334.374 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.335.649 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.338.914 CtrlSrv:ff3288d0:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.338.969 CtrlSrv:ff3288d0:00:00: <<< INT-0Ah done
32.348.913 CtrlSrv:0001c398:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.349.006 CtrlSrv:0001c398:00:00: <<< INT-0Ah done
32.349.302 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.349.421 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.351.963 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2632 dword=342
32.353.274 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.354.555 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.355.818 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.357.072 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.358.915 CtrlSrv:ff4b85fc:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.359.000 CtrlSrv:ff4b85fc:00:00: <<< INT-0Ah done
32.368.913 CtrlSrv:ff4ba004:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.368.961 CtrlSrv:ff4ba004:00:00: <<< INT-0Ah done
32.369.080 CtrlSrv:ff6914c8:83:03: StopLiveViewAFFrameAppFromMain
32.373.780 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2632 dword=342
32.375.098 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.376.371 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.377.651 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.378.913 CtrlSrv:ff4cfbec:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.379.000 CtrlSrv:ff4cfbec:00:00: <<< INT-0Ah done
32.379.853 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.379.970 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.380.050 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.388.915 CtrlSrv:ff328658:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.388.979 CtrlSrv:ff328658:00:00: <<< INT-0Ah done
32.395.504 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2632 dword=342
32.396.812 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.398.065 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.398.915 CtrlSrv:ff4cfbec:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.398.957 CtrlSrv:ff4cfbec:00:00: <<< INT-0Ah done
32.399.410 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.400.713 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=2888 dword=378
32.408.913 CtrlSrv:ff4c1a14:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.408.998 CtrlSrv:ff4c1a14:00:00: <<< INT-0Ah done
32.409.292 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.409.411 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.413.858 CtrlSrv:ff68af58:83:03: StopLiveViewBackgroundApp
32.417.656 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=4000 dword=0
32.418.914 CtrlSrv:ff4cfbbc:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.418.954 CtrlSrv:ff4cfbbc:00:00: <<< INT-0Ah done
32.419.338 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=4400 dword=0
32.420.932 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=4400 dword=0
32.422.482 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=4400 dword=0
32.424.014 CtrlSrv:ff4cfb9c:04:02: TransparentBitmap byte=4400 dword=0
32.428.913 CtrlSrv:ff4d024c:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.428.957 CtrlSrv:ff4d024c:00:00: <<< INT-0Ah done
32.435.546 CtrlSrv:ff524560:83:01: PopColorPalette
32.435.745 CtrlSrv:ff66badc:83:01: StopGuidanceActive(0x0)
32.435.886 CtrlSrv:ff39daa0:83:03: IDLEHandler GOT_TOP_OF_CONTROL
32.435.901 CtrlSrv:ff521618:83:03: CancelDateTimer
32.435.934 CtrlSrv:ff521624:00:00: *** CancelTimer(0x17)
32.438.914 CtrlSrv:ff4b7a38:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.438.992 CtrlSrv:ff4b7a38:00:00: <<< INT-0Ah done
32.439.285 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.439.407 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.441.606 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.441.806 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.441.953 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.442.090 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.442.226 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.442.369 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.442.511 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.442.657 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.442.794 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.442.935 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.443.072 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.443.208 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.443.351 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.443.495 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.443.636 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.443.770 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.443.910 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.444.051 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.444.190 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.444.332 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.444.478 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.444.615 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.444.753 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.444.890 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.445.033 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.445.172 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.445.320 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.445.460 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.445.598 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.445.737 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.445.878 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.446.022 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.446.168 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.446.311 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.446.446 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.446.580 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.446.719 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.446.856 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.446.992 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.447.130 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.447.274 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.447.414 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.447.556 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.447.699 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.447.832 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.447.974 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.448.115 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.448.256 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.448.394 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.448.532 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.448.673 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.448.811 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.448.913 DisplayMgr:00016db8:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.448.952 DisplayMgr:00016db8:00:00: <<< INT-0Ah done
32.449.028 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.449.180 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.449.319 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.449.454 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.449.593 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.449.737 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.449.877 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.450.016 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.450.159 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.450.300 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.450.431 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.450.568 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.450.704 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.450.845 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.450.988 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.451.122 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.451.257 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.451.399 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.451.536 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.451.678 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.451.818 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.451.958 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.452.100 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.452.237 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.452.377 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.452.517 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.452.661 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.452.793 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.452.928 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.453.069 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.453.210 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.453.351 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.453.495 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.453.631 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.453.770 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.453.911 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.454.052 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.454.190 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.454.327 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.454.474 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.454.619 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.454.754 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.454.898 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.455.043 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.455.185 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.455.328 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.455.468 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.455.611 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.455.757 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.455.890 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.456.035 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.456.173 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.456.314 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.456.449 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.456.582 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.456.724 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.456.864 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.457.007 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.457.148 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.457.293 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.457.433 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.457.576 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.457.721 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.457.861 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.458.003 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.458.146 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.458.291 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.458.433 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.458.572 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.458.718 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.458.858 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.458.915 DisplayMgr:00002b9c:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.458.964 DisplayMgr:00002b9c:00:00: <<< INT-0Ah done
32.459.095 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.459.248 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.459.400 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.459.546 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.459.679 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.459.817 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.459.961 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.460.108 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.460.248 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.460.384 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.460.522 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.460.666 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.460.813 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.460.957 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.461.090 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.461.236 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.461.372 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.461.523 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.461.662 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.461.809 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.461.948 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.462.087 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.462.229 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.462.368 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.462.512 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.462.652 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.462.785 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.462.922 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.463.059 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.463.194 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.463.331 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.463.476 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.463.615 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.463.756 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.463.893 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.464.033 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.464.172 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.464.312 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.464.457 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.464.597 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.464.747 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.464.890 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.465.036 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.465.180 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.465.323 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.465.466 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.465.607 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.465.747 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.465.891 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.466.031 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.466.169 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.466.312 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.466.448 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.466.589 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.466.734 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.466.878 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.467.017 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.467.158 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.467.310 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.467.455 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.467.599 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.467.744 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.467.886 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.468.030 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.468.172 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.468.310 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.468.450 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.468.592 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.468.732 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.468.872 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.468.911 CtrlSrv:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.468.969 CtrlSrv:ff0c1118:00:00: <<< INT-0Ah done
32.469.253 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.469.376 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.469.576 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.469.722 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.469.859 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.470.004 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.470.155 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.470.296 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.470.441 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.470.581 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.470.715 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.470.856 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.470.999 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.471.136 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.471.270 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.471.409 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.471.551 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.471.687 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.471.825 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.471.973 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.472.107 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.472.248 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.472.393 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.472.536 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.472.679 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.472.820 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.472.964 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.473.103 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.473.241 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.473.381 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.473.523 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.473.663 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.473.801 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.473.937 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.474.079 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.474.207 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.474.342 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.474.480 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.474.622 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.474.761 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.474.903 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.475.036 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.475.172 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.475.308 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.475.451 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.475.596 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.475.739 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.475.886 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.476.032 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.476.173 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.476.311 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.476.458 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.476.600 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.476.743 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.476.887 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.477.028 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.477.175 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.477.314 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.477.455 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.477.603 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.477.752 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.477.896 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.478.040 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.478.184 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.478.326 CtrlSrv:ff12e870:82:02: [Post]SetPaletteWithIndexToDisplayDeviceWithoutEnableEngine 153
32.478.486 CtrlSrv:ff12e870:82:02: [Post]ChangePhysicalScreen 165
32.478.568 DisplayMgr:ff129428:82:02: SetBitmapVramAddress pBitmap_Address=41380008
32.478.593 DisplayMgr:ff1299ec:82:02: SetParameterToBitmapDisplayDevice
32.478.698 DisplayMgr:ff1285a0:82:02: EnableBitmapVBufferForPlayBackAndWait WaitBmpCBR=ff12e880
32.478.791 livev_hipr:000ba500:00:00: *** msleep(0x64)
32.478.850 audio_comm:000b2798:00:00: *** msleep(0xa)
32.478.960 focus_task:00002780:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.479.013 focus_task:00002780:00:00: <<< INT-0Ah done
32.479.632 audio_comm:000b2798:00:00: *** msleep(0xa)
32.479.768 PtpDps:ff0fe9fc:33:01: Dispatch : Cur = 0, Event = 88, Param = 0x0
32.479.792 PtpDps:ff2a9e38:33:03: PtpCamCtrlCheckAudioLevelStart
32.479.852 PtpDps:ff0fe9fc:33:01: Dispatch : Cur = 0, Event = 9, Param = 0x0
32.479.893 PtpDps:ff2969fc:33:01: ptpPropertyChangeEvent[205000e][4][2][0]
32.479.924 PtpDps:ff287464:32:01: GetConnectSessionFirst end[0][3]
32.479.957 PtpDps:ff2a2464:33:01: PROP:0x205000e,2
32.480.000 PtpDps:ff287464:32:01: GetConnectSessionFirst end[0][3]
32.480.025 PtpDps:ff287658:32:01: GetConnectSessionHandle 1 err[0][0]
32.480.043 PtpDps:ff287464:32:01: GetConnectSessionFirst end[0][3]
32.480.057 PtpDps:ff287658:32:01: GetConnectSessionHandle 1 err[0][0]
32.480.081 PtpDps:ff2a124c:33:01: ptpGetPropEvent FAILED! [d195][0]
32.480.169 clock_task:000a498c:00:00: *** msleep(0xc8)
32.480.232 run_test:0009c214:00:00: *** msleep(0x14)
32.480.896 cls_task:000b8c48:00:00: *** msleep(0x64)
32.481.735 notifybox_:0008f9bc:00:00: >>> INT-68h FF129ABC(00000000)
32.481.800 **INT-68h*:ff129b04:82:01: VdInterruptHandler bmp=ff12e880 img=0 localWaitBmpCBR=ff127cd8
32.481.826 **INT-68h*:ff12e894:82:01: WaitCBR pParam=0
32.481.849 notifybox_:0008f9bc:00:00: <<< INT-68h done
32.488.906 CtrlSrv:0001c394:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.488.954 CtrlSrv:0001c394:00:00: <<< INT-0Ah done
32.493.579 CtrlSrv:ff4d7790:04:02: refresh whole fReverseScreen=0
32.493.623 CtrlSrv:ff1aca40:84:01: copyDataToStorage eventID(0x80050022)Data(1)size(0)
32.493.658 CtrlSrv:ff1b0e80:83:03: PROP_LV_ACTION[1]
32.493.843 CtrlSrv:ff1aca40:84:01: copyDataToStorage eventID(0x205000e)Data(2)size(0)
32.494.108 audio_comm:000b2798:00:00: *** msleep(0xa)
32.496.270 notifybox_:000a0d78:00:00: *** msleep(0x32)
32.496.323 fps_task:000a2938:00:00: *** msleep(0x14)
32.496.368 console_ta:000c7e4c:00:00: *** msleep(0xc8)
32.496.440 tweak_task:00094438:00:00: *** msleep(0x32)
32.496.590 debug_task:0008c228:00:00: *** msleep(0xc8)
32.496.646 focus_misc:000a08d4:00:00: *** msleep(0x64)
32.496.698 livev_lopr:000b3174:00:00: *** msleep(0xc8)
32.498.912 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.498.988 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.499.284 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.499.402 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.499.475 audio_comm:000b2798:00:00: *** msleep(0xa)
32.499.535 run_test:000bec40:00:00: *** msleep(0x64)
32.508.912 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.508.961 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.509.004 audio_comm:000b2798:00:00: *** msleep(0xa)
32.509.057 fps_task:000a2938:00:00: *** msleep(0x14)
32.518.908 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.518.952 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.518.991 audio_comm:000b2798:00:00: *** msleep(0xa)
32.528.906 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.528.976 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.529.268 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.529.388 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.529.461 audio_comm:000b2798:00:00: *** msleep(0xa)
32.529.585 fps_task:000a2938:00:00: *** msleep(0x14)
32.538.913 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.538.964 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.539.085 audio_comm:000b2798:00:00: *** msleep(0xa)
32.541.920 notifybox_:000a0d78:00:00: *** msleep(0x32)
32.542.007 tweak_task:00094438:00:00: *** msleep(0x32)
32.548.911 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.548.961 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.549.005 audio_comm:000b2798:00:00: *** msleep(0xa)
32.549.055 fps_task:000a2938:00:00: *** msleep(0x14)
32.558.907 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.558.983 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.559.279 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.559.397 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.559.472 audio_comm:000b2798:00:00: *** msleep(0xa)
32.568.912 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.568.956 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.568.997 livev_hipr:000ba500:00:00: *** msleep(0x64)
32.569.047 audio_comm:000b2798:00:00: *** msleep(0xa)
32.569.087 fps_task:000a2938:00:00: *** msleep(0x14)
32.578.909 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.578.949 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.578.990 audio_comm:000b2798:00:00: *** msleep(0xa)
32.579.045 cls_task:000b8c48:00:00: *** msleep(0x64)
32.588.910 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.588.992 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.589.834 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.589.952 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.590.105 audio_comm:000b2798:00:00: *** msleep(0xa)
32.592.896 notifybox_:000a0d78:00:00: *** msleep(0x32)
32.592.947 fps_task:000a2938:00:00: *** msleep(0x14)
32.592.992 focus_misc:000a08d4:00:00: *** msleep(0x64)
32.593.062 tweak_task:00094438:00:00: *** msleep(0x32)
32.598.914 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.598.970 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.599.017 audio_comm:000b2798:00:00: *** msleep(0xa)
32.601.965 run_test:0008b5a4:00:00: *** msleep(0xfa)
32.608.910 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.608.961 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.609.005 audio_comm:000b2798:00:00: *** msleep(0xa)
32.609.057 fps_task:000a2938:00:00: *** msleep(0x14)
32.618.907 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.618.981 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.619.277 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.619.396 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.619.474 audio_comm:000b2798:00:00: *** msleep(0xa)
32.628.913 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.628.960 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.629.002 audio_comm:000b2798:00:00: *** msleep(0xa)
32.629.137 fps_task:000a2938:00:00: *** msleep(0x14)
32.638.911 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.638.961 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.639.081 audio_comm:000b2798:00:00: *** msleep(0xa)
32.641.876 notifybox_:000a0d78:00:00: *** msleep(0x32)
32.641.958 tweak_task:00094438:00:00: *** msleep(0x32)
32.648.911 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.648.994 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.649.279 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.649.400 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.649.477 audio_comm:000b2798:00:00: *** msleep(0xa)
32.649.528 fps_task:000a2938:00:00: *** msleep(0x14)
32.658.913 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.658.960 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.659.003 audio_comm:000b2798:00:00: *** msleep(0xa)
32.668.908 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.668.953 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.668.995 livev_hipr:000ba500:00:00: *** msleep(0x64)
32.669.047 audio_comm:000b2798:00:00: *** msleep(0xa)
32.669.088 fps_task:000a2938:00:00: *** msleep(0x14)
32.678.908 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.678.985 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.679.273 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.679.392 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.679.468 audio_comm:000b2798:00:00: *** msleep(0xa)
32.679.527 clock_task:000a498c:00:00: *** msleep(0xc8)
32.679.580 cls_task:000b8c48:00:00: *** msleep(0x64)
32.688.913 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.688.981 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.689.658 audio_comm:000b2798:00:00: *** msleep(0xa)
32.692.452 notifybox_:000a0d78:00:00: *** msleep(0x32)
32.692.506 fps_task:000a2938:00:00: *** msleep(0x14)
32.692.551 console_ta:000c7e4c:00:00: *** msleep(0xc8)
32.692.621 debug_task:0008c228:00:00: *** msleep(0xc8)
32.692.670 focus_misc:000a08d4:00:00: *** msleep(0x64)
32.692.742 tweak_task:00094438:00:00: *** msleep(0x32)
32.692.866 livev_lopr:000b3174:00:00: *** msleep(0xc8)
32.698.913 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.698.962 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.699.003 audio_comm:000b2798:00:00: *** msleep(0xa)
32.708.907 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.708.981 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.709.269 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.709.391 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.709.467 audio_comm:000b2798:00:00: *** msleep(0xa)
32.709.518 fps_task:000a2938:00:00: *** msleep(0x14)
32.718.911 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.718.958 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.719.001 audio_comm:000b2798:00:00: *** msleep(0xa)
32.728.908 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.728.956 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.728.999 audio_comm:000b2798:00:00: *** msleep(0xa)
32.729.116 fps_task:000a2938:00:00: *** msleep(0x14)
32.738.912 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.738.995 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.739.286 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.739.404 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.739.555 audio_comm:000b2798:00:00: *** msleep(0xa)
32.742.349 notifybox_:000a0d78:00:00: *** msleep(0x32)
32.742.434 tweak_task:00094438:00:00: *** msleep(0x32)
32.748.914 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.748.966 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.749.012 audio_comm:000b2798:00:00: *** msleep(0xa)
32.749.066 fps_task:000a2938:00:00: *** msleep(0x14)
32.758.908 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.758.954 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.758.994 audio_comm:000b2798:00:00: *** msleep(0xa)
32.768.908 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.768.978 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.769.272 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.769.389 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.769.464 livev_hipr:000ba500:00:00: *** msleep(0x64)
32.769.523 audio_comm:000b2798:00:00: *** msleep(0xa)
32.769.568 fps_task:000a2938:00:00: *** msleep(0x14)
32.778.913 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.778.964 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.779.005 audio_comm:000b2798:00:00: *** msleep(0xa)
32.779.065 cls_task:000b8c48:00:00: *** msleep(0x64)
32.788.913 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.788.970 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.789.644 audio_comm:000b2798:00:00: *** msleep(0xa)
32.792.434 notifybox_:000a0d78:00:00: *** msleep(0x32)
32.792.488 fps_task:000a2938:00:00: *** msleep(0x14)
32.792.534 focus_misc:000a08d4:00:00: *** msleep(0x64)
32.792.606 tweak_task:00094438:00:00: *** msleep(0x32)
32.798.912 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.798.993 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.799.290 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.799.407 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.799.490 audio_comm:000b2798:00:00: *** msleep(0xa)
32.808.913 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.808.960 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.809.000 audio_comm:000b2798:00:00: *** msleep(0xa)
32.809.054 fps_task:000a2938:00:00: *** msleep(0x14)
32.818.907 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.818.946 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.818.987 audio_comm:000b2798:00:00: *** msleep(0xa)
32.828.907 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.828.984 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.829.267 TouchMgr:ff334164:c1:02: [TCH] G:0 F:0 O:0 B:0 Cnt0 #0 X0 Y0 0 0 ID(0,0)
32.829.386 TouchMgr:ff3352c0:00:00: *** SetTimerAfter(0x14, 0xff333700, 0xff333700, 0x92a484)
32.829.460 audio_comm:000b2798:00:00: *** msleep(0xa)
32.829.582 fps_task:000a2938:00:00: *** msleep(0x14)
32.838.912 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.838.959 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.839.083 audio_comm:000b2798:00:00: *** msleep(0xa)
32.840.076 notifybox_:0008f9d8:00:00: >>> INT-50h MREQ FF31AB78(00000000)
32.840.132 **INT-50h*:ff138e04:00:01: [PM] DisablePowerSave (Counter = 2)
32.840.156 **INT-50h*:ff138e74:00:01: [PM] EnablePowerSave (Counter = 1)
32.840.177 notifybox_:0008f9d8:00:00: <<< INT-50h done
32.840.206 notifybox_:0008f9d4:00:00: >>> INT-36h SIO3 FF31ABFC(00000000)
32.840.231 notifybox_:0008f9d4:00:00: <<< INT-36h done
32.840.255 notifybox_:0008f9d4:00:00: >>> INT-36h SIO3 FF31ABFC(00000000)
32.840.266 notifybox_:0008f9d4:00:00: <<< INT-36h done
32.840.289 notifybox_:0008f9e0:00:00: >>> INT-36h SIO3 FF31ABFC(00000000)
32.840.324 **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 05 03 38 9d 00)
32.840.397 notifybox_:0008f9e0:00:00: <<< INT-36h done
32.840.716 Gmt:ff181a78:9a:01: gmtProperty ID=0x80030035(0x9d)
32.840.805 Gmt:ff0d5a9c:9a:01: Event 19 Result State 9->9 ID 0x80030035(157)
32.842.690 notifybox_:000a0d78:00:00: *** msleep(0x32)
32.842.774 tweak_task:00094438:00:00: *** msleep(0x32)
32.848.914 PowerMgr:ff0c1118:00:00: >>> INT-0Ah Timer FF0C15AC(00000000)
32.848.968 PowerMgr:ff0c1118:00:00: <<< INT-0Ah done
32.849.013 audio_comm:000b2798:00:00: *** msleep(0xa)
32.849.054 run_test:0008b5b4:00:00: Pause LiveView Done?
In this LOG we can also see what EDMACs channels are related to which functions which is cool. so I tried to call each function which shut down a LiveView process, I avoided functions which are related to Preview (YUV paths) and RAW data, I started to call them one by one, the interesting ones are:
32.311.895 AeWb:ff261f58:98:03: [AEWB] aewbSuspend
32.312.193 LVFACE:ff17d650:aa:03: lvfaceEnd
32.312.547 LVFACE:ff2c6edc:00:00: *** SetEDmac(0xc, 0x0, 0x0, 0x0)
32.313.647 Evf:ff19d588:ad:01: Cartridge Cancel[0]
1-aewbSuspend:
Calling this will disable aewb function (driver?), Side Effects:
-White Balance and Exposure settings will be locked, you will not able to change them, in our case only during RAW video recording. This alone gains ~7 MB/s .
-Shutter fine-tuning won't work properly, since this feature based on aewb task. Not sure if there is a workaround for that, didn't dig into it.
2-lvfaceEnd:
I am not sure what LVFACE task is for, it's related to to EDMAC channel #12, from what I understand LVFACE is for face/subject tracking feature?
Calling it gains ~3MB/s, didn't notice any side effects during my tests, I didn't make tests with autofocus enabled.
3-Cartridge Cancel:
I have no idea about this, it gains ~3MB/s by calling it. Side Effect: in some resolutions I had only the first frame corrupted in RAW video recording.
-Notes:
1-Managed to record more than ~128 GB of MLV files in different modes, I didn't have any crash, *no corrupted frames.
(*in some cases only the first frame when Cartridge Cancel hack is enabled, not always, all other thousands of frames were fine).
2-These hacks are being enabled only when you record RAW video (once you hit the record button), once RAW video recording stops, by default mlv_lite will pause LiveView during buffer flush, then it will resume LiveView which means all hacks would be disabled/reset.
3-It should work on all DIGIC 5 modes, DIGIC 4 cameras have these functions too, I can expect an improvment on 5D2 (DIGIC 4 models with CF interface).
4-Use it at your own risk.
5- Tested on 700D and 5D3.123, both works as explained above, 5D3 got also ~13 MB/s improvement ;D
-Using the hacks:
You can see them in RAW video submenu (mlv_lite), lvfaceEnd hack is enabled by default.
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FPhHzGXX%2Flvface.png&hash=331d81710df72836a65589d2a4990b42)
-You need to enable aewbSuspend and CartridgeCancel manually as this photo showing:
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2F1r7BH3f%2Fall-hacks-enabled.png&hash=855ffef454d35fc15137f614bc3e2883)
-More hacks: includes lvfaceEnd and aewbSuspend.
-One more hack: includes CartridgeCancel.
-feel free to play with them and make your own tests (disable one of them.. etc).
-Downloads:
-650D/700D:
In my 650D / 700D (T4i / T5i) thread (https://www.magiclantern.fm/forum/index.php?topic=25784.msg231049#msg231049)
-5D3 (113/123)
Danne builds. (https://bitbucket.org/Dannephoto/magic-lantern_dannephoto_git/downloads/) (Updated)
-EOSM:
Danne builds. (https://bitbucket.org/Dannephoto/magic-lantern_jip_hop_git/downloads/) (Updated)
-6D
Levas's custom build for 6D (https://www.magiclantern.fm/forum/index.php?topic=25782.msg223031#msg223031) with this mlv_lite.mo (https://www.magiclantern.fm/forum/index.php?topic=26443.msg238378#msg238378).
-I already found the stubs for these cameras and decided to port these hacks immediately, EOSM and 5D3 builds are based on latest Danne builds.
-Source code:
Download my repository for 650D/700D, and open it with SourceTree so you can see the commit:
magic-lantern-bilal (7-4-2022).7z (https://drive.google.com/file/d/14DxuWGPjoCcIZaaQxGUiEKQoTr3xMRAJ/view?usp=sharing) (crop_rec_4k branch)
-Stubs:
0xff261f34 700D.115 aewbSuspend
0xff17d63c 700D.115 lvfaceEnd
0xff19d558 700D.115 CartridgeCancel
0xff23ff10 5D3.123 aewbSuspend
0xff16e318 5D3.123 lvfaceEnd
0xff181340 5D3.123 CartridgeCancel
0xff23bc60 5D3.113 aewbSuspend
0xff16d77c 5D3.113 lvfaceEnd
0xff17fd68 5D3.113 CartridgeCancel
0xff2606f4 EOSM.202 aewbSuspend
0xff177ff8 EOSM.202 lvfaceEnd
0xffa7e7d8 EOSM.202 CartridgeCancel
0xff25fb90 650D.104 aewbSuspend
0xff17c564 650D.104 lvfaceEnd
0xff19b9b4 650D.104 CartridgeCancel
0xff24c5e4 6D.116 aewbSuspend
0xff170d08 6D.116 lvfaceEnd
0xffceffdc 6D.116 CartridgeCancel
0xff258818 70D.112 aewbSuspend
0xff1702d8 70D.112 lvfaceEnd
0xffd6b71c 70D.112 CartridgeCancel
0xff253f98 100D.101 aewbSuspend
0xff16f49c 100D.101 lvfaceEnd
0xffab6bcc 100D.101 CartridgeCancel
0xff10fa28 60D.111 aewbSuspend
0xff0fb9d4 60D.111 lvfaceEnd
0xff263cd8 60D.111 CartridgeCancel
0xff1134ac 600D.102 aewbSuspend
0xff0fc424 600D.102 lvfaceEnd
0xff281278 600D.102 CartridgeCancel
0xff1c60fc 1200D.102 aewbSuspend
0xff1ae510 1200D.102 lvfaceEnd
0xff345fdc 1200D.102 CartridgeCancel
0xfe1a6fdc 1300D.110 aewbSuspend
0xfe1a6fdc 1300D.110 lvfaceEnd
0xfe34bd1c 1300D.110 CartridgeCancel
Have fun!
-
Good job Bilal. Really, good job
-
I tried it on my 5d3 (113) and it works, but i'm only getting about 3 MB/s improvement. Nice, but not 13!
Is there something in the operation you didn't mention that might be obvious only to you?
-
wow, this is pure magic! congratulations!
-
When you think there is nothing more to gain...amazing 8)
Although I miss a particular camera in that list :P
Would love to try this on the 6d.
Are you able to add the 6d in too, or do you need some info ?
-
I tried it on my 5d3 (113) and it works, but i'm only getting about 3 MB/s improvement. Nice, but not 13!
Is there something in the operation you didn't mention that might be obvious only to you?
I can definitely get at least ~10MB/s on my 5D3.123.
Have you enabled all the hacks from RAW video submenu manually?
-Set "More hacks" to "lvfaceEnd + aewbSuspend"
-Set "One more hack" to "ON"
If you already did these, what CF card are you using? run card benchmarks in photo mode (using Bench.mo), share the result.
-My configuration:
Cards used:
CF: Sandisk Extreme PRO 160 MB/s UDMA7
SD Sandisk Extreme PRO 170 MB/s U3 UHS-I (with 160 MHz SD overclock)
Benchmarks:
-Photo mode:
CF SD Card Spanning
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FWF05x7d%2FCF-Photo.png&hash=83c16940d67d6f34fe62ffe222de2cdb) (https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FMZKfCyg%2FSD-Photo.png&hash=cd03ca16c609de8e7f04b920438a2472) (https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FdcnnpYM%2FCard-Spanning-Photo.png&hash=13851cee5815247af3bf4c41b1d93c45)
-LiveView 1080p24 (with small hacks)
CF Card Spanning (result: 120.2 MB/s)
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2Fwztc59f%2FCF-small-hacks.png&hash=2e57bda5de4dd91be293ddeed0fef028) (https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FSy0VvfG%2Fsmall-hacks-card-spanning.png&hash=1d612fb97637b5833d3df8d13c9e76c8)
-LiveView 1080p24 (small hacks combined with the new hacks)
CF Card Spanning (result: 133.1 MB/s)
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FByBwvcn%2FCF-small-hacks-with-new-hacks.png&hash=b4c9c8d15faf1ee601b6b59e3bcb923e) (https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FMsNRrkQ%2Fsmall-hacks-with-new-hacks-Card-Spanning.png&hash=de9942461c1df72e9f05883a0e745740)
-CF card alone gained 9.3 MB/s write speed
-Card Spanning gained 12.9 MB/s write speed
-Running benchmarks with these hacks (the small hacks and the new ones) requires code modification, these hacks are only enabled when recording RAW video. So you can't get CF/card spanning benchmarks with the provided builds.
-I will downgrade to 1.1.3 later and do some tests.
-Currently you can make some tests like I did in Demo video, setup a static scene, make RAW video recording tests with and without the new hacks.
-
thanks for the update.
i'm only using the sd card for my test, since i thought that's where the gain would be...
sandisk 170 mb/s, same overclocking settings as you.
can you try just the sd card to see what you get?
-
Good job Bilal. Really, good job
Thanks man!
-
wow, this is pure magic! congratulations!
Actually, it is! I didn't believe that we finally got around write speed bottleneck.
-
When you think there is nothing more to gain...amazing 8)
Although I miss a particular camera in that list :P
Would love to try this on the 6d.
Are you able to add the 6d in too, or do you need some info ?
Haha, yeah!
Stubs updated, added 6D ones too :D
ff24c5e4 6D.116 aewbSuspend
ff170d08 6D.116 lvfaceEnd
ffceffdc 6D.116 CartridgeCancel
I can add support for 6D, but I couldn't find your custom source code for 6D, mlv_lite.c should be enough (my mlv_lite.c has hardcoded modification for 650D/700D).
I provided my source code in the first post with the commit if you want to take a look into it.
-
Bilal, you are a genius! Tried 5D3.113 and from very early tests it seems to have unlocked continuous rec. @ 3.5K (that is, 3584 x 1500 1:1 25 fps @14 bit)!
Thank you man!
Sergio
-
i'm only using the sd card for my test, since i thought that's where the gain would be...
sandisk 170 mb/s, same overclocking settings as you.
can you try just the sd card to see what you get?
That explains. Okay, results with only SD card and 160 MHz overclock:
Photo mode 1080p24 Small hacks 1080p24 Small hacks with the new hacks
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FMZKfCyg%2FSD-Photo.png&hash=cd03ca16c609de8e7f04b920438a2472) (https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FJdR57v8%2FSD-small-hacks.png&hash=5da1eccb2c1b6b3c745c804fdd66c820) (https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2F26d9nJ2%2FSD-small-hacks-new-hacks.png&hash=46db3226d8a27399903ee30edc67ba7d)
It's actually 3.3 MB/s improvement here.
-
yeah, i enabled both cards and spanning and i also now have continuous recording at 3616*1536 23.976 @14 bits (unless overexposed)
amazing...
bilal, you are putting the magic back into magic lantern, brother!
-
@theBilalFakhouri
I tested your build with my 5DIII, but I see a problem:
If I enable aewb and I record a underexposed scene, it changed exposure while recording - > lighten it up. It is visible in ML app too, but I can't see change settings.
EDIT:
I found the problem... This is only happen if you use shutter fine tuning too.
EDIT2:
I reached a write speed of 149mb/s.
I stopped manually after 1 min. (orange indicator)
Nice Job!
-
@EOS M users:
Updated the build in the first post (https://www.magiclantern.fm/forum/index.php?topic=26443.msg238349#msg238349), the first build I provided didn't enable the new hacks, please try the updated build, report back.
-EOSM:
crop_rec_4k_mlv_snd_raw_only_2022Apr07.EOSM202.zip (https://bitbucket.org/bilal_fakhouri/magic-lantern/downloads/crop_rec_4k_mlv_snd_raw_only_2022Apr07.EOSM202.zip) (Updated)
-
-DIGIC 4 models: unfortunately these functions are not presented in 5D2 :(
Initially I thought it would be there because 60D and 600D both have these functions, but 5D2 and 550D don't.
It could be there similar functions with other names in 5D2 (or something we can disable). who knows.
-
Bilal, you are a genius! Tried 5D3.113 and from very early tests it seems to have unlocked continuous rec. @ 3.5K (that is, 3584 x 1500 1:1 25 fps @14 bit)!
Thank you man!
Sergio
yeah, i enabled both cards and spanning and i also now have continuous recording at 3616*1536 23.976 @14 bits (unless overexposed)
amazing...
bilal, you are putting the magic back into magic lantern, brother!
Nice results, thanks for testing.
Enjoy.
@theBilalFakhouri
I tested your build with my 5DIII, but I see a problem:
If I enable aewb and I record a underexposed scene, it changed exposure while recording - > lighten it up. It is visible in ML app too, but I can't see change settings.
EDIT:
I found the problem... This is only happen if you use shutter fine tuning too.
EDIT2:
I reached a write speed of 149mb/s.
I stopped manually after 1 min. (orange indicator)
Nice Job!
Thanks for reporting this, and for testing.
I might take a look later into shutter fine tuning with these hacks, and will see if can do something about it.
149 MB/s is probably not real, unless you are using lower FPS, which mode you are using?
-
It also works for 6d, Bilal made and update of MLV_lite module, thanks Bilal :)
For those that wants to test on 6d, here's the link to the MLV_lite module file, replace it with the one on your card:
https://drive.google.com/file/d/1trrpR00vqtJh2SC-HpTfG43rS8tUCAZc/view?usp=sharing (https://drive.google.com/file/d/1trrpR00vqtJh2SC-HpTfG43rS8tUCAZc/view?usp=sharing)
The "more hacks" function works, use lvface + aewb setting for best results.
The "One more hack" function doesn't work on 6d for now, recording doesn't start with this enabled ???
Improvement ~6MB/s
Without I get about ~86MB/s write speed
With more hacks enabled I get ~92MB/s write speeds 8)
-
I'm definitely getting 140 MB/S on my 5d3 (113)
It fluctuates slightly in the load balancing between the two cards, generally around 60 for the SD and 80 for the CF.
Unfortunately sustained clipping, even mild, eventually leads to stopping.
I like to shoot challenging scenes with the green channel clipping a little bit, which is easily (automagically) corrected in post, and even that causes the recording to eventually stop. It only needs a tiny bit more throughput!
Here's hoping it gets found one day :)
But a very slight reduction in resolution fixes that for now!
This should give plenty of headroom for the 3.3 and 3.5k modes with the realtime preview :)
-
Thanks for reporting this, and for testing.
I might take a look later into shutter fine tuning with these hacks, and will see if can do something about it.
149 MB/s is probably not real, unless you are using lower FPS, which mode you are using?
3.5K Preset in 3584x1730, at 23.976fps at 14bit lossless. With your Hacks, SD Overclocking and card spanning. Filming static scene.
I double checked the filezise on my computer. mb / frames x 23.976.
Without your hacks I reached up to 139mb in my older tests
Sometimes the first frame is corrupt but the rest is good.
But I think this writespeed is really bleeding edge: If I use raw zebras histogram and waveform (with Kill global draw), the record stops automatically after a while (also with green indicator), camera shutdown and say Battery low. With dummy Battery it stops, but without shutdown. And without waveform it works fine (with Battery) .
-
Very cool! Will take a look as soon as possible. Thanks for sharing a build for the eos m and 5D3.
-
This is beyond awesome! Definitely Black Magic Lantern ;)
I fully trust in your builds, and I've never had any problem. I assume that's also the case with this one :)
-
Unfortunately sustained clipping, even mild, eventually leads to stopping.
Confirmed. However continuous rec. can be achieved killing Global Draw. This was not sufficient before Bilal's hacks. So once again, thanks!
Sergio
-
Time for some tests 8)
Very short tests but shiwed improvements for 2.8k. "one more hack" caused freeze. Will investigate further.
-
Anybody testing this hack with eos m and hdmi out?
-
"one more hack" caused freeze. Will investigate further.
The same with 6d, but it's not just a freeze. Trashcan button to enter ML menu is responsive.
In ML menu you can see that it's starting raw video, but it never starts :P
Switching off the camera gives clean shutdown, so no ordinary freeze.
-
Yeah, something strange there Levas :).
By the way bilal. More hacks says exposure and white balanse will be locked. Testee behaviour but seems exposure is still changeable while recording on my eos m. Changing, iso, shutter and aperture, while filming, also changes exposure on the screen?
-
Currently avoid using Cartridge Cancel a.k.a "one more hack" on EOS M and 6D. as I wrote in the first post I have no idea what it does.
Be aware this is the only hack which may produce RAW data corruption in some cases (during my tests only first frame was affected, other were fine. but still there is a possible RAW data corruption).
I found also Cartridge Clear function (we are not using it in our hacks), calling it would suspend all EDMACs channel activity, probably Cartridge may mean EDMACs channels.
Of course take these hacks and info with grain of salt. :) This thread is a nice proof of concept that proves we can gain extra write speed.
@names_are_hard suggested that we may be able to lower other tasks priority in LiveView, without killing the tasks (without suspending aewb).
There are more stuff to dig into it, if someone want a faster progress feel free to contribute.
-
Yes, very cool stuff.
Tested some more and using more hacks freezes when hd 1080p is selected. Probably since it´s in crop mode. Regular x3 zoom and 1x3 binning modes(anamorphic all works. So don´t use these hacks with HD 1080p mode for now.
-
3.5K Preset in 3584x1730, at 23.976fps at 14bit lossless. With your Hacks, SD Overclocking and card spanning. Filming static scene.
I double checked the filezise on my computer. mb / frames x 23.976.
Without your hacks I reached up to 139mb in my older tests
Cool, what CF card are you using? mind running CF card benchmarks in Photo mode?
Sometimes the first frame is corrupt but the rest is good.
Yeah, I had the same thing. This happens with "One more hack" enabled, other hacks didn't produce first frame corruption. Double checking with "One more hack" disabled is a good idea.
But I think this writespeed is really bleeding edge: If I use raw zebras histogram and waveform (with Kill global draw), the record stops automatically after a while (also with green indicator), camera shutdown and say Battery low. With dummy Battery it stops, but without shutdown. And without waveform it works fine (with Battery) .
Sometime I have speed drops and suddenly stops on 700D. more tests are needed for me to make sure and figure out what's happening. I will make more tests on 5D3 in future and will see if I can reproduce your issue too.
-
This is beyond awesome! Definitely Black Magic Lantern ;)
I fully trust in your builds, and I've never had any problem. I assume that's also the case with this one :)
Thanks, you may want to make some real tests too with the new stuff before giving a full trust :).
-
Tested some more and using more hacks freezes when hd 1080p is selected. Probably since it´s in crop mode. Regular x3 zoom and 1x3 binning modes(anamorphic all works. So don´t use these hacks with HD 1080p mode for now.
Just tested the new hacks in movie crop mode on 700D, it seems lvfaceEnd hack is causing freezing here too, only in MCM. but "One more hack" appears to work.
-
Tested all three hacks separately but nothing worked when in mcm mode on eos m. Other presets seems fine though :).
-
Tested all three hacks separately but nothing worked when in mcm mode on eos m. Other presets seems fine though :).
Nice, could you post some results from EOSM, write speed with and without the hacks (recording time in a static scene before and after).
-
Testing against 2.8k in 12bit, 24fps I get around 600 frames with the hack lvface + aewb and without it records about a 100 frames. With 10bit I get continuous while without the hack around 260 frames. I think we are recording around 65MB/s here.
Correction. One more hack will still freeze all modes.
-
Cool, what CF card are you using? mind running CF card benchmarks in Photo mode?
A Kingston Canvas 128gb (not the fastest, but cheap) - > benchmark CF only: 115W, 146R
But I tested my Komputerbay 128gb now too. I reached unbelievable 156mb/s - > ~7848mb / 1203 frames x 23.976 = ~156 (after 40s stopped automatically) - > Benchmark CF only 119W, 152R
Benchmark CF + SD: 155W
But there is no change in Benchmark with and without your hacks.
I will make more tests on 5D3 in future and will see if I can reproduce your issue too.
I think the shut down problem was the Battery itself, maybe not full recharged or something.
-
Holy crap ! Just tried it on eos M , i set 2.8k 10 bit, 24fps , sd overclock 192-240, got 61-62MB rec speed and i was able to record one minute, it stopped at 01:05...
Danne heres HDMI output when i record 2.8k in this new version, half of the screen is pink stripes
So that means now 3k is possible to implement on eos M ?
I set 3k and reg 6014 to 480 and got 23.3 fps , i can get 30secs this way but 23.980 wont get me even 5secs with 6014 set to 525.My cardwrite speed on PC is 80MB
Sadly all other non crop modes are broken, and hang the camera when pressing record, so i cant record in fullsensor width modes.
Ok turning off lvface hack fixes camera hanging on non crop modes but its the one hack that helps the most to gain extra speed.
How i can capture 5D2 log to provide You with correct addresses for lvface and awbd functions that are needed to make it work on 5D2 ?
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FWtdmPbT%2Fhdmi.jpg&hash=e0f704504a05d9eeec0c03aa9cf7b045)
-
Just tried on my eos M,
Test conditions:
- 192mhz mode
- Lvface +aewb hacks
- “One more hack” OFF => as Danne mentioned direct freeze
- Same over exposed scene for all tests
- Sandisk Extreme Pro 170mb/s
2.8K – 10 bits – 23.981fps
- Before: around 11s
- After: continous (manually stopped after more than 10 minutes)
3K (3008x1280) – 10 bits – 23.3fps (reg_6014 = -480 / reg_6008 = 0)
- between 10 and 15s
Great job Bilal, the 2.8K can now be used and the 3K seems not that far :)
-
Anybody testing this hack with eos m and hdmi out?
How do I do eos-m screen captures? The hdmi output is acting strange:
If I use a phone with usb cam installed, It outputs 2K 1:1 correctly, but in other modes it outputs only the interface overlay, but the video preview is garbled.
If I connect the eos m to the hdmi input of my Asus Computer Monitor, the 2k 1:1 mode doesn't work, 5K ana and 1080p work but freeze, and 2.5K and 2.8K modes output half a squeezed video preview with the second half pink.
So, I went back to the June 2021 build to make sure: only 2k 1:1 works when using the phone as monitor, and using the Asus Monitor, only 5k Ana and 1080P outputs correctly. I still get half a squeezed screen in 2.5k and 2.8k
So it seems like it depends on what is on the hdmi receiving end, because Zeek said it works for him in all modes when using the june 2021 build.
Any ideas or other tests I could do to help out?
-
First post is updated with a fresh eosm build from original code. This version skips "One more hack" and also skips running in hd 1080p mode.
-
Danne heres HDMI output when i record 2.8k in this new version, half of the screen is pink stripes
To fix that PINK HDMI screen: in ML tab 3, go to 'customized buttons', Disable x3 Crop Toggle and Focus Aid
-
I don't have one more hack on the eosm
is it not on the eosm?
-
EOS M Test Results using HDMI Monitor:
Build: crop_rec_4k_mlv_snd_raw_only_2022Apr10.EOSM202.zip, link in first post
SD Card: Sandisk Extreme Pro 170 MB/s, 128GB
192MHz Hack
In order for the hdmi output to work reliably, the presets need to be changed using the "Tap Display". When connecting an hdmi monitor, the screen tap doesn't work (The eos screen is disabled). So we could go to 3rd ML Menu, customized buttons, and put "INFO SELECTABLE" to "Off" and change "Dropdown List" to "INFO", but then lose whatever function was assigned to the Info button. We could also disconnect the hdmi cable to select presets, but I don't think this would be recommended as the Mini hdmi connector isn't "Industrial Strength) :)
Also, in order for all the different presets to work reliably, without Pink / Green half screen, squeezed display, freezed display; in 3rd ML Menu Disable x3 Crop Toggle and Disable Focus Aid. Those 2 functions won't be needed if using a field monitor with pinch-to-zoom or zoom functions.
If using a phone with USB Camera or another capture app installed as a monitor, only the 2k 1:1 preset works (Tested with LG V30, Samsung Galaxy S8, Hagbis UHC06 capture dongle)
Edit: When using a capture dongle with a phone and usb camera, the dongle needs to be connected to the phone BEFORE powering it on. That way, 2K, 2.5K and 2.8K presets work (But the screen shows only part of the actual recorded image). When changing presets, resolution, etc, the EOS-m needs to be restarted. My hdmi monitor (Asus) doesn't work with 2.5K (At any aspect ratio), but some people got their monitors working when using a 16:9 ratio). Maybe we could post working configurations in a dedicated thread to make it easier for everyone... My USB camera Video Format settings are: MJPEG, 1920x1080 60p
The Benchmark module doesn't write the results as a .ppm file (image file) on the card anymore, but I get 61.9 / 63.9 MB/s Write speed, which are the exact same figures I had when running the June 26 2021 Build. The recording times have been expanded significantly though:
5K frtp:
14bit 23.976 fps, recorded over 3 minutes once, and several 1 minute clips in a row, no interruptions (Orange light).
12bit 23.976 fps, records continuously (>3 minutes).
2.5k:
14bit 23.976 fps, toggles between green and orange light, Always records past 1 minute, but on one trial, it stopped after 2:30 minutes.
12bit 23.976 fps, records continuously (>3 minutes)
2.8K:
12 bit 23.976 fps, records between 1-2 minutes.
10 bit 23.976 fps, records continuously, orange light.
For the tests, I shot tree branches towards an overcast sky, with the histogram showing between E1.0 and E0.4
-
Nice test report!
So, just to be sure. All tests reported here includes the use of a hdmi monitor? Except the usb camera test that is.
-
Nice test report!
So, just to be sure. All tests reported here includes the use of a hdmi monitor? Except the usb camera test that is.
Correct. I used the HDMI input of an ASUS PB278Q. If you could point me to some info on how the hdmi out works, I could try to find out why the usb dongles and the lower end field monitors are so finnicky.
-
Unfortunately not using hdmi port personally so nice that this could be tested like this. What about frame corruption? Did it seem like files were ok or did you spot any pink frames here and there?
-
Those long clips take forever to convert! I will let you know in a few days, as I need to look at everything very closely to spot focus dots, glitches, etc. So that whoever reading the comment can use it accordingly.
-
I see. I think some general use cases will reveal any issues pretty early but I could be wrong. But great if you can check some on your side since you seem to do a good job here.
-
Some results.
I recorded two batches of about 30 clips each. I reviewed Both batches today, so here are my findings:
When adding the hack "Lvface+aewb", using HDMI monitor or not, if I set the shutter fine tune so that I get between 1/46 and 1/48 (a little above 1/46 gives the appropriate blur we're used to, 1/48 seems faster than expected), the value of the shutter jumps to 1/30 as soon as I hit record. It shows in the recorded file, as you see the exposure ramping up within the first 10 frames or so (using other fine tune values will shift the exposure relative to the value).
Putting Shutter fine tune to "off" will keep a steady 1/50.
Using only "Lvface" instead of "Lvface+aewb" fixes this Shutter issue, but 2.8k recording will redline at 12 bit and record about 20 seconds.
So using only the "Lvface" hack and hdmi monitor, the figures are as follows:
2.8K:
12 bit 23.976 fps, records about 20 seconds.
10 bit 23.976 fps, records continuously, between green and orange light.
No pink or dropped frames, focus pixels can be seen clearly while recording, but are taken care of with mlvapp.
Following Danne's hint about resolution:
14bit 23.976 fps, if I lower the resolution to 2656x1112, I get at least 30 seconds, oscillating between red and orange light.
14bit 23.976 fps, If I lower the resolution to 2608x1092, I get at least 1 minute (Stopped myself on each trial), always in orange light, no red.
2.5K:
Speed Results are the same, but lots of pink frames regardless of the bit depth. even restarting the camera does not fix it. So, not usable with an HDMI monitor for now.
Edit: See Reply#42, it works with a phone and capture dongle in my case (And no pink frames), when connecting the dongle before turning on the phone, and also when powering off the camera after each settings / preset change)
5K ana frtp: The results are similar to my previous post (Reply #42), no pink or dropped frames and no focus pixels.
2K: Continuous recording at every bit depth. No corrupt frames.
Out of 60 clips, I got 3 corrupted clip, which would not open (2.8k).
When using the hdmi monitor, when switching presets, the connection to the monitor is often lost. You have to shutdown the camera and it runs fine on restart.
Like I mentioned in the previous post, using the hdmi monitor disables the tap screen dropdown list. So I have to assign the dropdown list to the info button.
But, when pressing info, you have to turn the wheel quickly, because it chooses a preset by itself as soon as you stop spinning the wheel.
Also, I noticed that every preset uses a different center (Those scan different parts of the sensor) and if I use the 2.5K Centered preset as a reference, the presets are often a little to the right, with the 5K preset scanning towards the lower portion of the sensor (Which at least give you a chance to get the eyes in better focus if filming a person when using an older lens).
It would be good to disclose the exact offset figures, as this would allow people to choose the right lens accordingly. Unless you use an ef-m 32mm f1.4 or, to a slightly lesser extent, ef-m 22mm f2; you don't get edge to edge sharpness. So, if you use a Helios or a c-mount lens, you will get uneven bokeh and vignetting, as those vintage lenses get softer and blurrier very quickly as soon as you deviate from the center. (Not too apparent if you do nature shots, but a lot more if you frame a subject off center.)
Zooming also requires reframing, when symmetry is needed. A non technical person will easily overlook those details and will have to learn the hard way, after wondering for hours if they were drunk the day of the shoot :)
-
Interesting. So 2.8k shows better results than 2.5k when it comes to pink frames.
So there's a shutter issue when +aewb i selected? And only with hdmi I suppose?
-
Interesting. So 2.8k shows better results than 2.5k when it comes to pink frames.
So there's a shutter issue when +aewb i selected? And only with hdmi I suppose?
The shutter issue, when +aewb is selected, occurs with and without hdmi monitor. It does so at every resolution / preset, and I restarted the camera after each preset change to make sure.
Just so I can avoid having to test everything empirically, If I were to start with the 2.8k preset, and lower the resolution from there, regarding raw buffers and what is happening behind the scenes, should I theoretically get the same behavior as selecting the 2k preset, for example?
Also, what is the advantage of scanning the top part of the sensor, as opposed to scanning it dead center?
-
Yes, reducing 2.8k preset should give good results. Not sure what's up with shutter. Will check later.
-
1-aewbSuspend:
Calling this will disable aewb function (driver?), Side Effects:
-White Balance and Exposure settings will be locked, you will not able to change them, in our case only during RAW video recording. This alone gains ~7 MB/s .
-Shutter fine-tuning won't work properly, since this feature based on aewb task. Not sure if there is a workaround for that, didn't dig into it.
Updated the side effects for aewb hack. Shutter fine-tuning feature confirmed to not work properly with aewb hack. Tested on 5D3 (https://www.magiclantern.fm/forum/index.php?topic=26443.msg238373#msg238373), 700D (me) and EOSM (https://www.magiclantern.fm/forum/index.php?topic=26443.msg238437#msg238437).
-
Could you share the fix?
-
I don't have a fix, not sure if it fixable. Didn't look into it yet . .
-
Ok, I misunderstood 8).
-
Just so I can avoid having to test everything empirically, If I were to start with the 2.8k preset, and lower the resolution from there, regarding raw buffers and what is happening behind the scenes, should I theoretically get the same behavior as selecting the 2k preset, for example?
Realizing height is probably causing corruption with hdmi out. 2.8k runs max 1190 height whereas 2.5k up t around 1400. Probably too much too handle for hdmi.
-
Congratulations, Bilal, to your new amazing achievement!
I performed initial tests with your build: "crop_rec_4k.2022Apr07.700D115"
and it worked right ouf the box, even with Dual ISO ! The 1736x2928 provides continuous recording at 18 fps now, with a few corrupt frames now and then. The shutter speed indicator seems to be broken though but I have to check with one of the other three builds to see if it works. In the above build it shows some odd numbers like 1/92s or 1/170s in this and also other modes and these numbers do not change when you adjust the shutter speed dial. In earlier builds this indicator used to work fine. Also, I could't get the timelapse mode at 5208x2928 (1:1) working at frame rates higher than 2,5 fps. Camera records just one frame and stops recording.
EDIT:
I kept testing with the build: "crop_rec_4k.2022Apr07.700D115_Shutter_Blanking_ISOless"
The shutter issue is gone now, Dual ISO works fine too. With a slight underexposure, in the Full Width LV mode I get continuous recording at 1376x2306/12bit/24fps with a few corrupt frames. The number of corrupt frames increases when I get closer to overexposure. Dual ISO seems to produce less corrupt frames probably because it boosts the shadows and avoids crushing them.
What is quite annoying is this box full of text that appears quite often on the screen after recording starts. It goes away only upon turning camera off and on again.
I do have a question regarding resolutions in the 1x3 anamorphic modes. Would it be possible to increase them in such manner that they take advantage of the 13 MB/s write speed improvement without ending up with corrupt frames?
I will illustrate what I mean with one example. My favorite mode is the 1312x2214/10bit/24fps/16:9. When I use it now, it gives me about 45.3 MB/s recording speed which is way lower than what the camera is up to, (83 MB/s according to your measurements on page 1). Unfortunately, camera will only allow me to increase the horizontal but not the vertical resolution for the desired 16:9 aspect ratio. Could this be fixed somehow? I am asking because it appears that mostly the 2.35:1 aspect ratio benefits from the speed improvement. I think a resolution of 1600x2700/10bit/24fps (16:9) or similar would be absolutely gorgeous.
-
hi IDA_ML
for shutter problem you can use crop_rec_4k.2022Apr07.700D115_Shutter_Blanking_ISOless.zip build instead..
-
Yes, ML700D, I just edited my post.
You are a big fan of Dual ISO, aren't you? Well, I have very good news for you. Your 700D creates miracles with Dual ISO 100/800 with the Full-res LV preset at 18 fps now: 1736x2928/10bit/18fps/1/33s. You have to be very careful with exposure though. Even slight over or underexposure will produce corrupt frames. But once you get it right, you will enjoy a very clean and naturally looking image. Just give it a try and report back!
-
I just edited Reply #48, for those who would like to know more about using the latest build with an hdmi monitor.
-
Also, I noticed that every preset uses a different center (Those scan different parts of the sensor) and if I use the 2.5K Centered preset as a reference, the presets are often a little to the right, with the 5K preset scanning towards the lower portion of the sensor (Which at least give you a chance to get the eyes in better focus if filming a person when using an older lens).
It would be good to disclose the exact offset figures, as this would allow people to choose the right lens accordingly. Unless you use an ef-m 32mm f1.4 or, to a slightly lesser extent, ef-m 22mm f2; you don't get edge to edge sharpness. So, if you use a Helios or a c-mount lens, you will get uneven bokeh and vignetting, as those vintage lenses get softer and blurrier very quickly as soon as you deviate from the center. (Not too apparent if you do nature shots, but a lot more if you frame a subject off center.)
It is possible to alter offset with cmos registry. They are present in the crop rec submenu under advanced I believe. Don't emember exactly which two cmos regs but shouldn't ve too hard to find out.
-
Great!Danne!I reuse my 6d again to take 5k video!
-
It's completely theBilalFakhouris work here 8).
-
Yes, ML700D, I just edited my post.
You are a big fan of Dual ISO, aren't you? Well, I have very good news for you. Your 700D creates miracles with Dual ISO 100/800 with the Full-res LV preset at 18 fps now: 1736x2928/10bit/18fps/1/33s. You have to be very careful with exposure though. Even slight over or underexposure will produce corrupt frames. But once you get it right, you will enjoy a very clean and naturally looking image. Just give it a try and report back!
nice.. ok, I will try it later, I'm big fan of Bilal's crop rec 4k 😁
could you give me mlv sample of that setting? I want to see.
thanks IDA_ML.
-
ML700D,
Unfortunately, I do not have that sample any more. I filmed a scene outside throudh the window and got some of the room interior in the frame to capture a high-contrast/high dynamic range scene. Then I examined the clip in MLVApp right from the card and was very pleased with the result. Then I deleted the file since I did not needed it any more. I just remember that, after adjusting the sliders, the histogram filled the entire area starting at 0 on the left and ending with 0 on the right without over or underexposure.
-
I just tried the new small hacks on my 650D (more hacks with two hacks and one more hacks enabled). I don't know how to implement this on my 5d3 so I just skip it now.
On 650D, I tested two modes with SD card overclocking at 240 mhz with a Sandisk Extreme Pro 170MB/s 256 GB SD card.
1. UHD 1X3 14-bit 14-bit lossless, without dual ISO, with auto ettr, with waveform, with zebra, with magic zoom and focus, global on, the benchmark was about 68 MB/s. This mode is continuous even at ISO 1600, with a benchmark at 62 MB/s. So this mode is very robust and practical.
I did test global draw off without waveform, zebra, focus, magic zoom, the benchmark was about 71 MB/s.
2. Full frame 5.2k 1x3 10-bit 14-bit lossless global draw off without waveform, zebra, focus, magic zoom, the benchmark was 65 MB/s.
It seems that in both modes, the writing speed is about 5 MB/s better than before.
Update:
Turning off the more hacks and one hacks on 650D, the benchmark is still 68 MB/s in UHD 1X3 14bit/14bit lossless mode. So it seems no improvement? Not sure what happened. I checked the ML version is 4/7/2022.
Update:
In 650D's 5.2k 1x3 full APS-C sensor mode, I remembered that the 1-minute benchmark for the last ML version was about 60 MB/s with global draw on, with the current version, the 1-minute benchmark is 63.5 MB/s with global draw on, 67.5 MB/s with global draw off. So there is about 3 MB/s improvement for writing speed. However, activating the three small hacks does not improve further using the 1-minute benchmark test.
-
Recording with a preset isn't benchmarking. Recordings will probably show the same but the hacks will allow for longer or continuous shooting.
-
Recording with a preset isn't benchmarking. Recordings will probably show the same but the hacks will allow for longer or continuous shooting.
Thanks. Will try this.
5.2k 1x3 recording using the current ML version without hacks on, the recording time is 1-2 seconds with global draw on, 20 seconds with global draw off.
With the three hacks on, the recording time is more than 1 minutes with global draw on, most time indicator is orange, sometimes is red. Now it is already 7 minutes recording time. With global draw off, the indicator is green, the recording time is more than 1 minutes, manually terminated. So it is continuous.
So 1-minute benchmark does not reflect the true improvement. Thanks Dan and Bil. It is a great achievement.
I think that now 650D is an APS-C 5K raw camera with hardware compression ratio of 3. Although software compression may have better recovery with smart algorithms, 650D 5.2k 1x3 footage very possibly will stack against other raw cameras' 5K footage at a compression ratio of 12 or even 8 or 6.
Cheers,
Update
For an indoor relatively dark scene, ISO 1600:
1. 5.2k 1736x2214 1x3 10 bit 14bit lossless, global draw off, recording indicator mostly orange, sometimes green, recording speed 75 MB/s, 1-2% idle, recorded more than 10 minutes, manually terminated. I consider this continuous. With global draw on, the recording time is about 3 seconds. I think 1736x1950 AR 2.67 will be continuous with global draw on. Will test it later. Update: It is green, one minute recording, terminated manually. Continuous.
2. UHD 1X3 14 bit color depth 14 bit lossless, global draw off, recording indicator orange, recording speed 70 MB/s, idle time gradually increase from 100 ms to 900 ms after 5 minutes recording, manually terminated. I consider this continuous. With global draw on, it is continuous also.
3. 3K 1x1 10 bit color depth 14 bit lossless, AR 2.67, global draw off, recording indicator green, recording speed 72.5 MB/s, 2% idle, continuous. AR 2.4, recording indicator red to orange, recording speed 79 - 80 MB/s, 1% idle, more than 1 minutes, sometimes more than 5 minutes, scene dependent, stopped automatically.
Thus, all these three modes are robustly continuous even in challenging scenes. If the three hacks prove no serious side effects, these modes can be used in practice fairly stably.
Update:
For a scene composed of several tree with dense green leaves, a parking lot with several cars, a gate with iron fences
during the sunny noon at ISO 100
using a EFS lens 10-18 IS at 10 mm, IS on, AF off
UHD 1X3 14 bit color depth 14 bit lossless LJ92 compression records at 80 MB/s.
With global draw always on, the recording time is about 3 seconds. However, if push the info button to enter the user interface 2, where I typically change the shutter speed here, the indicator is orange to green, continuous recording. It is almost like with global draw off.
Thus,
I rate the Canon 650D ML as a raw news camera with the following specs:
14 bit 4K raw with a hardware compression ratio of 3
35mm/4-3 sensor size
continuous at ISO 100
If using a preset to reserve high dynamic range in MLV App, the dr may reach 12 stops.
This Canon 650D ML is an Arri Amira mini disguised, at the cost of 1%.
The same setting at late evening, needs ISO 1600, F 4.5, shutter speed 30, still a little bit dark. The writing speed is about 72 MB/s for 14 bit color depth.
Therefore, 14 bit UHD 1X3 AR 16-9 is usable most of the time in the user interface 2. For some extreme cases like late afternoon when the writing speed is over 82 MB/s, 12 bit can be used, which cuts the writing speed to 75 MB/s, and continuous.
Personally I settle on 12 bit color depth UHD 1X3 AR 16-9. This bit rate generates 75 MB/s peak data stream, plus 5 MB/s global draw, still less than the current 82 MB/s limit. I like the global draw very much and want to operate everything in user interface 1 with global draw on.
Update
The same set up as above, 12 bit UHD, handheld, 90 seconds footage, processed in MLV App with default setting, export to mp4. The footage has no first frame corruption, no pink or corrupted frame in duration. The dynamic range is good. The sharpness is acceptable. It seems to me that 650D UHD 1X3 12 bit mode can be used for run and gone news shooting safely.
Update
The same set up as above
1. 5.2K 1X3 1736X2272 10 bit 24 fps
AR 2.35, writing speed 78 MB/s, continuous global draw off, <3 seconds global draw on;
AR 2.39, writing speed 74 MB/s, continuous global draw off, 10-30 seconds global draw on;
AR 2.67, writing speed 65 MB/s, continuous global draw on.
2. 3X3 720 P 50 FPS 10 bit
AR 2.39, 1736x698, writing speed 68 MB/s, continuous global draw off, 10-30 seconds global draw on.
Update
The same set up as above.
1. 1280 1x1 mode, 1920x1280 1X1 14 bit 24 fps, writing speed 65 MB/s, continuous global draw on.
2. 1440 1x1 mode, 1920x1440 1X1 12 bit 24 fps, writing speed 65 MB/s, continuous global draw on.
3. 2.5k 1x1 mode, 1920x1280 1X1 10 bit 30 fps, writing speed 65 MB/s, 10 seconds global draw on.
Update
3x3 60 fps 1736x586 mode, 14 bit lossless, writing speed 64 MB/s, 4 seconds, global draw on; 12 bit lossless, writing speed 56 MB/s, 4 seconds, global draw on; 11 bit lossless, writing speed 50 MB/s, 18 seconds, global draw on. Seems this mode is not optimized enough. But in real world, 10 seonds of slow motion in 24 fps is enough.
3x3 24 fps 1736x976 mode, 14 bit lossless, writing speed 44 MB/s, green, global draw on.
3x3 30 fps 1736x976 mode, 14 bit lossless, writing speed 55 MB/s, green, global draw on.
If the traditional setting of AR 16-9 plus 30 fps is required, this mode is the only way to go. The operation in this mode is very convenient and reliable, pushing set button to do auto ettr, pushing zoom in to have 5x 10x high resolution enlargement, pushing zoom out to have low resolution magic zoom during video recording, pushing info button to access 4 different user interfaces.
-
I think that now 650D is an APS-C 5K raw camera with hardware compression ratio of 3. Although software compression may have better recovery with smart algorithms, 650D 5.2k 1x3 footage very possibly will stack against other raw cameras' 5K footage at a compression ratio of 12 or even 8 or 6.
By hardware compression ratio of 3, do you mean subjectively?
1x3 Binning isn't exactly compression. What you lose is mostly sharpness (And detail resolution), because every 3 horizontal pixels are combined into one. (But every line is scanned, thus, vertical resolution is relatively untouched)
-
By hardware compression ratio of 3, do you mean subjectively?
1x3 Binning isn't exactly compression. What you lose is mostly sharpness (And detail resolution), because every 3 horizontal pixels are combined into one. (But every line is scanned, thus, vertical resolution is relatively untouched)
I think so. Hardware binning loses information permanently. Software compression may recover some information by smart codec and algorithms. However, heavy software compression will lose information. This is very often seen on commercial camcorders, the in-camcorder codec is so heavy that the footage is not so great, but the through hd sdi or hdmi to external recorder the uncompressed stream has much better quality. Software codec at compression ratio of 6 and above will have certain loss of information.
-
By hardware compression ratio of 3, do you mean subjectively?
1x3 Binning isn't exactly compression. What you lose is mostly sharpness (And detail resolution), because every 3 horizontal pixels are combined into one. (But every line is scanned, thus, vertical resolution is relatively untouched)
REDCODE is a mathematically lossy codec, meaning that decompression does not fully restore the original image data captured by the camera. Red claims the codec is "visually lossless", suggesting that the information loss is not visible to the naked eye when images are viewed.
https://www.dpreview.com/forums/thread/3091209#forum-post-39762774
https://www.afcinema.com/IMG/pdf/2/c/e/955-0001_v31.6.16_rev-a_red_cs_red_one_operation_guide.pdf
The highest Redcode on Red One is Redcode 42, 42 MB/s. It was a great achievement at the time. Now 650D ML can do 80 MB/s, equal to Redcode 80. Hehe.
-
By hardware compression ratio of 3, do you mean subjectively?
1x3 Binning isn't exactly compression. What you lose is mostly sharpness (And detail resolution), because every 3 horizontal pixels are combined into one. (But every line is scanned, thus, vertical resolution is relatively untouched)
Let us take a look using 650D's UHD versus the original Red One Classic as an example.
650D UHD 1x3 12 bit generates about 70-80 MB/s for a typical complex scene. Red One's RedCode 28 generates 28 MB/s no matter the scene complexity. RedCode 28 has a compression ratio of 8. 650D in UHD mode has a sensor size of 4-3, close to Red One's super 35mm sensor size. 650D's data files are about 2 to 3 times larger than RedCode 28. Certainly Red's patented codec is very good and keeps more information than 650D's simple and dumb un-stretching algorithms (we can see it as a hardware-software combined codec, although lossy and may not be efficient). But still the final footage may be very close, simply due to the much bigger data size of the 650D files.
Some one who has Black Magic's 4k cameras or the original Red One cameras can do this kind of comparison. I know BMPCC 4K or 6K has raw compression ratio to the 12.
"REDCODE range is 2:1 to 22:1. Default is 8:1. For maximum available REDCODE values, see the DSMC Media Operation Guide."
http://docs.red.com/955-0154_v7.0/REDRAVENOperationGuide/en-us/Content/4_Basic_Menus/REDCODE.htm
https://www.provideocoalition.com/red_one_geekery_real_world_info_on_redcode/
-
@mlrocks , This is very interesting. Did you have a chance to compare the output of the 650D to that of the eos-m? As the 650D is quite affordable, it could be interesting.
-
@mlrocks , This is very interesting. Did you have a chance to compare the output of the 650D to that of the eos-m? As the 650D is quite affordable, it could be interesting.
I do not have EOS M any more.
Theoretically, EOS M is the same as 650D/700D, just different body and flange distance. But I did not compare both ML versions side by side.
-
In my experience, the 700D provides less noise and a cleaner image in the darks compared to the EOS-M. I don't know why. It could be a different sensor or some kind of noise reduction at RAW level but overall the image of the 700D looks cleaner in the shadows.
-
less noise and a cleaner image in the darks compared to the EOS-M
It could be better power filtration, different dc/dc converters and all analog stuff around the sensor and a/d conversion. EOS-M is so compact they could sacrifice some performance in order to fit everything in that tiny form-factor..
For example, in audio world two different audio interfaces with identical chips inside can have different characteristics. And it is mainly because of a difference in power, shielding and all that stuff. Basically, analog stuff around the digital chip.
-
Dxo rates eos m sensor higher than 700d
https://www.apotelyt.com/compare-camera/canon-700d-vs-canon-m
I expect more or less no visible difference given test setup is the same. Anybody having both cameras could post two cr2 files for us to compare. Needless to say. Same test condition needed.
-
After some Easter family shooting, I can conclude that these LV hacks boosted my 5D3 (1.1.3) write speed from 115-120 MB/s to 130-135 MB/s in real-life situations.
Switched to 14-bit 3.5K (that should be called 3.7K actually IMO) definitively. I just cannot do exact ETTR in very bright conditions and complex scenes -- in these cases I have to stop down 1/3 to 1 EV in order to achieve continuous recording, sometimes also killing Global Draw. Happy to pay that price though.
I'm definitely getting 140 MB/S on my 5d3 (113)
What cards are you using? I definitely cannot reach above 135 MB/s.
Sergio
-
After some Easter family shooting, I can conclude that these LV hacks boosted my 5D3 (1.1.3) write speed from 115-120 MB/s to 130-135 MB/s in real-life situations.
Switched to 14-bit 3.5K (that should be called 3.7K actually IMO) definitively. I just cannot do exact ETTR in very bright conditions and complex scenes -- in these cases I have to stop down 1/3 to 1 EV in order to achieve continuous recording, sometimes also killing Global Draw. Happy to pay that price though.
What cards are you using? I definitely cannot reach above 135 MB/s.
Sergio
Did you use sd card overclocking on 5D3? How long was your shooting session? Did you experience overheating and related corrupted frames? Thanks.
-
Did you use sd card overclocking on 5D3? How long was your shooting session? Did you experience overheating and related corrupted frames? Thanks.
Yes, overclocking enabled, as well as card spanning of course.
I took 96 clips in a 48h time frame approximatively, all 3.5K 1:1 centered @14 bit (some of which using Dual ISO as well), with the following stats:
- 32 automagically stopped ;), all with write speed > 135 MB/s (150 on average)
- the remaining 64 achieved continuous recording (short clips, 30 secs on average, apart from a longer one lasting more than 3 minutes), with write speed up to 135 MB/s (130 on average)
I would say that in broadly half of cases I got a slightly corrupted first frame (typically resulting in a pink area in the top 1/4 of the image), but apart from that only one clip had a (completely) corrupted frame in the middle of it (i.e. MLV App skipped it when converting to DNG). So this seems pretty reliable to me.
Also, no particular overheating observed (but again, my shooting sessions were very quick).
HTH
Sergio
-
Yes, overclocking enabled, as well as card spanning of course.
I took 96 clips in a 48h time frame approximatively, all 3.5K 1:1 centered @14 bit (some of which using Dual ISO as well), with the following stats:
- 32 automagically stopped ;), all with write speed > 135 MB/s (150 on average)
- the remaining 64 achieved continuous recording (short clips, 30 secs on average, apart from a longer one lasting more than 3 minutes), with write speed up to 135 MB/s (130 on average)
I would say that in broadly half of cases I got a slightly corrupted first frame (typically resulting in a pink area in the top 1/4 of the image), but apart from that only one clip had a (completely) corrupted frame in the middle of it (i.e. MLV App skipped it when converting to DNG). So this seems pretty reliable to me.
Also, no particular overheating observed (but again, my shooting sessions were very quick).
HTH
Sergio
Thank you for the detailed answer.
Is dual ISO on 5D3 reliable?
Also to IDAML:
Is dual ISO on 700D reliable?
No pink flash? Moire severe? etc.
If dual ISO works on 650D/700D and 5D3, basically these cameras are comparable to Arri Amira, which is the best news camera due to its high dr.
-
On 650D/700D first you need to select a stable RAW video mode, all presets in crop_rec "Crop mode" are stable (doesn't produce pink frames) with/without Dual ISO, also the normal Canon modes like (1080p, 720p, movie crop mode, x5 mode).
But if you are using arbitrary resolutions with crop_new (Crop mode V2), some settings would have pink/corrupted frames either with or without Dual ISO. crop_new isn't well fine-tuned yet, some settings will work without any problem like my favourite 1736x2214 1x3 @ 23.976 FPS (10-bit lossless), never had a problem with this mode on my 700D, also made a lot of tests with Dual ISO, this RAW video mode is stable.
Reducing FPS or RAW resolution a little in crop_new "Crop mode V2" should help to eliminate on pink/corrupted frames issues with your custom settings (don't push it to the limits).
But unfortunately currently I am not using Dual ISO much on 700D because it has flickering issue (https://www.magiclantern.fm/forum/index.php?topic=26180.msg236356#msg236356) on most RAW modes, I tested MLVApp, latest version of cr2hdr (on linux), both produce the same problem.
Some modes does work without the flickering issue like 4.5K 1x3 in "Crop mode".
-
On 650D/700D first you need to select a stable RAW video mode, all presets in crop_rec "Crop mode" are stable (doesn't produce pink frames) with/without Dual ISO, also the normal Canon modes like (1080p, 720p, movie crop mode, x5 mode).
But if you are using arbitrary resolutions with crop_new (Crop mode V2), some settings would have pink/corrupted frames either with or without Dual ISO. crop_new isn't well fine-tuned yet, some settings will work without any problem like my favourite 1736x2214 1x3 @ 23.976 FPS (10-bit lossless), never had a problem with this mode on my 700D, also made a lot of tests with Dual ISO, this RAW video mode is stable.
Reducing FPS or RAW resolution a little in crop_new "Crop mode V2" should help to eliminate on pink/corrupted frames issues with your custom settings (don't push it to the limits).
But unfortunately currently I am not using Dual ISO much on 700D because it has flickering issue (https://www.magiclantern.fm/forum/index.php?topic=26180.msg236356#msg236356) on most RAW modes, I tested MLVApp, latest version of cr2hdr (on linux), both produce the same problem.
Some modes does work without the flickering issue like 4.5K 1x3 in "Crop mode".
Thanks for your detailed answer, Bil. Is the UHD 1X3 immune to the flickering issue? I will try 4.5K 1x3 with dual ISO later.
Update:
I just tested 4.5K 1x3 with dual ISO, there is no flickering.
-
Thanks for your detailed answer, Bil. Is the UHD 1X3 immune to the flickering issue? I will try 4.5K 1x3 with dual ISO later.
Unfortunately, UHD 1x3 does have flickering issue, all other 1x3 presets have this problem except for 4.5K 1x3 which is weird . .
I just tested 4.5K 1x3 with dual ISO, there is no flickering.
Yeah, I am wondering how this preset don't introduce flickering, it worth digging into it. Will take a further look in future.
-
@vastunghia
Nice stats, thanks for sharing the results.
-
..
How i can capture 5D2 log to provide You with correct addresses for lvface and awbd functions that are needed to make it work on 5D2 ?
I got a log from Skinny (thanks), it seems 5D2 doesn't have these functions :( . Initially I thought it would be there because 60D and 600D both have these functions, but 5D2 and 550D don't.
So not all DIGIC 4 cameras have these.
I took a quick look into 5D2 log, it might be there some similar functions, no idea yet if it would work. Will take a further look later.
-
...
2.8K – 10 bits – 23.981fps
- Before: around 11s
- After: continous (manually stopped after more than 10 minutes)
3K (3008x1280) – 10 bits – 23.3fps (reg_6014 = -480 / reg_6008 = 0)
- between 10 and 15s
Great job Bilal, the 2.8K can now be used and the 3K seems not that far :)
Thanks for sharing, it's definitely an enhancement :).
-
A Kingston Canvas 128gb (not the fastest, but cheap) - > benchmark CF only: 115W, 146R
But I tested my Komputerbay 128gb now too. I reached unbelievable 156mb/s - > ~7848mb / 1203 frames x 23.976 = ~156 (after 40s stopped automatically) - > Benchmark CF only 119W, 152R
Benchmark CF + SD: 155W
Your Komputerbay CF card matches my Sandisk CF card benchmarks in Photo mode, same write speed ~119 MB/s, I thought your card might be faster.
~156 MB/s in LiveView isn't an accurate number, buffer size has an effect too on the calculations . . I will make tests later and will try to examine write speed based on your settings
ut there is no change in Benchmark with and without your hacks.
Yeah, because the hacks only works in LiveView . .
-
Is dual ISO on 5D3 reliable?
Dual ISO gave me no problem on the 5D3 so far. And in particular scenes, if used wisely, it yields impressive results.
Nice stats, thanks for sharing the results.
Thank you again Bilal, you are doing a terrific work!
If dual ISO works on 650D/700D and 5D3, basically these cameras are comparable to Arri Amira, which is the best news camera due to its high dr.
Yes, I love my 5D3 with ML, it is capable of delivering fantastic image quality at a stunning dynamic range.
In my view these are the two missing features that would make the 5D3 a real Raw workhorse:
- HDMI output with correct framing (or at least not so cropped) -- especially in 1:1 modes (don't even know if this is technically feasible): without this, checking focus (which is critical at high resolutions of course) is a pain in the neck
- SD overclock @higher speeds: on the 70D I can set it to 160 / 192 / 240 MHz, so porting this to the 5D3 (once again, if technically feasible) would potentially unlock continuous recording in more situations
Yeah, this is my personal list for Santa... ;)
Sergio
-
Unfortunately, UHD 1x3 does have flickering issue, all other 1x3 presets have this problem except for 4.5K 1x3 which is weird . .
Yeah, I am wondering how this preset don't introduce flickering, it worth digging into it. Will take a further look in future.
Another thing to consider:
The MLV App processing time for a 4.5k 1x3 dual ISO footage is about 4 times longer than a 4.5k 1x3 without dual ISO, about 10 to 12 times longer than a 1920x1280 1x1 without dual ISO. For fast turnaround time projects, 1x1 2k actually has such an advantage.
-
Is there a script or a way to do frame stacking (For Noise Reduction) from within MLV app?
-
Another thing to consider:
The MLV App processing time for a 4.5k 1x3 dual ISO footage is about 4 times longer than a 4.5k 1x3 without dual ISO, about 10 to 12 times longer than a 1920x1280 1x1 without dual ISO. For fast turnaround time projects, 1x1 2k actually has such an advantage.
DualISO processing is very complex and the actual algorithm is single threaded only. Yes - this is slow, but a lot of math.
But I don't think non-dualiso 4.5K is 2.5x..3x slower than 2K 1x1: the amount of pixels is more or less the same. The only difference is a single 3x stretching - but this is way faster than you write. As soon as you rescale 2K to e.g. 4K and 4.5K to 4K both will need more or less the same processing time.
Is there a script or a way to do frame stacking (For Noise Reduction) from within MLV app?
You can average n frames to one single frame. But this feature is more for creating dark frames. You won't get a video with that.
-
DualISO processing is very complex and the actual algorithm is single threaded only. Yes - this is slow, but a lot of math.
But I don't think non-dualiso 4.5K is 2.5x..3x slower than 2K 1x1: the amount of pixels is more or less the same. The only difference is a single 3x stretching - but this is way faster than you write. As soon as you rescale 2K to e.g. 4K and 4.5K to 4K both will need more or less the same processing time.
No offense, MASC. MLV App is a great software.
I am trying to configure my 650D as a practical news camera, balancing all of the major factors. I think the 12 bit 4.5k 1x3 dual ISO is probably the closest to the ARRI Amira, which is amazing, considering the price tag difference between the two. For short deadline projects, 1920x1280 14 bit 24 p is a good choice. For cinematic feelings, 5.2k 1x3 10 bit is the best, due to its super 35mm sensor size.
-
No offense, MASC. MLV App is a great software.
I am trying to configure my 650D as a practical news camera, balancing all of the major factors. I think the 12 bit 4.5k 1x3 dual ISO is probably the closest to the ARRI Amira, which is amazing, considering the price tag difference between the two. For short deadline projects, 1920x1280 14 bit 24 p is a good choice. For cinematic feelings, 5.2k 1x3 10 bit is the best, due to its super 35mm sensor size.
Interestingly, compared with 10 bit footage, 14 bit 2k 1x1 AR 3-2 24 fps, when shooting with auto/manual ettr, and elevating exposure one stop in MLV App, the output is very nice, similar to alexa/amira's high key footage, the noise in the dark area is not apparent. So, 14 bit is actually better than 10 bit, when using ettr, may gain one to 2 stops dr. For 10 bit shooting, better avoid ettr, because much of the information pushed to the dark side is lost and not saved in raw files.
In this term, 14 bit 4.5k 1x3 with ettr and dual iso may have a dr of 16 stops, 12 stops from the 650d raw file, 1-2 stops from ettr, 2-3 stops from dual iso. This dr is on par with the legendary alexa and amira's dr. 4.5k 1x3 raw also should be on par with the alexa/amira's 2.8k prores. The sensor size in 4.5k 1x3 mode is about 230 mm2, almost the same as 4-3's 224 mm2, although a little bit smaller than alexa/amira's super 35mm, this is good enough for news shooting, which requires large in focus zones. Imagine a lowly 650D/700D is Alexa/Amira or Red One in disguise, this is really something to talk about.
https://www.provideocoalition.com/alexa-dynamic-range-its-all-in-how-you-use-it/
https://www.newsshooter.com/2020/05/27/the-arri-alexa-is-10-years-old/
-
Great build
5D3 v1.1.3
3.5k 14bit lossless + dual ISO
aspect ratio 2:20
Dual card with Sandisk x1066
SD over locked
First frame almost always half pink (personally don't care)
I can get continues rec as long there not too much over exposure.
Its a game chager.
Thank you all devs!
Sent from my SM-P905 using Tapatalk
-
Great build
5D3 v1.1.3
3.5k 14bit lossless + dual ISO
aspect ratio 2:20
Dual card with Sandisk x1066
SD over locked
First frame almost always half pink (personally don't care)
I can get continues rec as long there not too much over exposure.
Its a game chager.
Thank you all devs!
Sent from my SM-P905 using Tapatalk
For dual ISO on 5d3, did you see flickering on the bright area?
-
I've been out of the ML world for a few years but this seems like a tempting development to jump back. What camera would people recommend for highest continuous resolution 16:9 to 2:20 and hdmi monitor out?
-
I've been out of the ML world for a few years but this seems like a tempting development to jump back. What camera would people recommend for highest continuous resolution 16:9 to 2:20 and hdmi monitor out?
Only 650d/700d can do correct high resolution hdmi out. EOS M may do that also. Thanks to Bil's work. Hope he can figure out the 5d3's realtime preview and hdmi out.
650D/700D UHD 1X3 preset has AR 16-9, 4K 1x3 preset has AR 2. I tested that both HDMI out works fine with my Zacuto 3 inch EVF.
5D3's 5.7k 1x3 preset has incorrect framing unstretched hdmi out. I can use Zacuto EVF's anamorphic ratio of 2 to do certainly level of unstretching that is good enough for rough framing, but the hdmi out framing is not correct.
-
Interestingly, compared with 10 bit footage, 14 bit 2k 1x1 AR 3-2 24 fps, when shooting with auto/manual ettr, and elevating exposure one stop in MLV App, the output is very nice, similar to alexa/amira's high key footage, the noise in the dark area is not apparent. So, 14 bit is actually better than 10 bit, when using ettr, may gain one to 2 stops dr. For 10 bit shooting, better avoid ettr, because much of the information pushed to the dark side is lost and not saved in raw files.
In this term, 14 bit 4.5k 1x3 with ettr and dual iso may have a dr of 16 stops, 12 stops from the 650d raw file, 1-2 stops from ettr, 2-3 stops from dual iso. This dr is on par with the legendary alexa and amira's dr. 4.5k 1x3 raw also should be on par with the alexa/amira's 2.8k prores. The sensor size in 4.5k 1x3 mode is about 230 mm2, almost the same as 4-3's 224 mm2, although a little bit smaller than alexa/amira's super 35mm, this is good enough for news shooting, which requires large in focus zones. Imagine a lowly 650D/700D is Alexa/Amira or Red One in disguise, this is really something to talk about.
https://www.provideocoalition.com/alexa-dynamic-range-its-all-in-how-you-use-it/
https://www.newsshooter.com/2020/05/27/the-arri-alexa-is-10-years-old/
After so much consideration, I finally settle down on 14-bit lossless UHD 1X3 with auto/manual ETTR without dual ISO on my 650D for raw news shooting, due to its AR 16-9, relative good low light performance, good image quality, acceptable pp computing time, correct real time color high resolution preview and magic zoom 2, etc. 14-bit lossless UHD 1X3 for a complex scene has a peak writing speed of 85 MB/s, I will go to user interface 2 (almost equivalent to global draw off but with certain essential information) and underexpose the scene to maintain the continuous recording, or go 12-bit lossless. Most of the time, though, the writing speed is below 78 MB/s, allowing to use the global draw in user interface 1.
-
For dual ISO on 5d3, did you see flickering on the bright area?
no, had 2 hours of great dual iso@3.5k 14 bit lossless 2:20
beside first frame pink
had nothing but continues stunning raw video.
Sent from my SM-N975F using Tapatalk
-
no, had 2 hours of great dual iso@3.5k 14 bit lossless 2:20
beside first frame pink
had nothing but continues stunning raw video.
Sent from my SM-N975F using Tapatalk
Great news!
Now 5D3 in 3.5K super 35mm mode is no less than Arri Alex 35mm series.
Any one here knows if dual ISO on 5D3 in 5.7K 1x3 mode has flickering in bright area?
Why Most Movies Are Shot On Arri Cameras
Reading the follow up comments is very interesting. Many experienced DP there.
"I have an Alex Mini LF and a red V raptor, Helium, C70, Blackmagic,Panny EVA1. The Alexa might have been way above over the competition 5-8 years ago, today? Not so much. The Alexa Look , besides the out of the box colors is this. Alexa digs deeper into the shadows. Whatever you shoot with Alexa tends to look HDR'ish. because the log curve digs into the shadows. As soon as you shoot something with any other camera and lift the shadows in post. Boom! Looks almost identical to the Alexa. Red V raptor is Cleaner also. Faster, cheaper, more compact, lighter. The only difference is the out of the box colors. Once you color correct every camera side by side? Alexa is nothing special."
"Alexa mini LF owner here, fortunately have been able to use just every digital cine camera from bmpcc6k (which I still own and use), and at least 8 different types of red cameras(komodo is valid) up to the Mini LF. Arri is truely the best camera company in the world. If you don't believe me, shoot a project on Arri with cooke 1.8 anamorphic or any high end glass and watch your mind be blown. Here's a music video I shot with that setup . It can make our jobs seem too easy at times but allows room for extreme creativity and style."
"Sony Venice has wider gamut, dynamic range and noise that is far more like film (variations in size over luminance). But the Arri is far harder to mess up the settings, and the Sony menu is a mess. I.e. the transition to digital from film was easier with the Arri. It’s easier to use, and harder to fruk up. I’ve posted over 100 features, and the Arri gets consistent results (I examine the metadata so I know what’s been done in the settings by the dop). imo the Sony creates better image both in it’s character and technical range, but is harder to learn how to use."
"The Sony Venice and especially the Venice 2 is absolutely beating out Arri even the Arri LF systems. Arri will always be considered an amazing camera system but they aren't adapting nearly as quickly as their competitors. We can't keep the Sony Venice on the shelf and have had DP's opt for the Venice 2 on major feature productions over Arri. Movies are no longer mostly shot on Arri cameras. Was this relevant 2 years ago, absolutely, but now the competition is getting too tight. Not to mention Panavision is still very popular and always was neck and neck with Arri."
Take home message: High end cameras are getting better and closer to each other now. Alexa still has an edge but not significant. 5D3 ML is getting there too. Once the realtime preview and the hdmi output is ported from 700D/650D by Bil the Great.
2h means 1TG footage? How long was the shooting session for this 2h footage? Did you experience the overheating due to sd card overclocking? What was the camera temperature? Did you buy all of the 2tg cf cards and sf cards? Will this take one to two weeks non-stopping pp computing time? Thanks.
-
Only 650d/700d can do correct high resolution hdmi out. EOS M may do that also. Thanks to Bil's work. Hope he can figure out the 5d3's realtime preview and hdmi out.
650D/700D UHD 1X3 preset has AR 16-9, 4K 1x3 preset has AR 2. I tested that both HDMI out works fine with my Zacuto 3 inch EVF.
5D3's 5.7k 1x3 preset has incorrect framing unstretched hdmi out. I can use Zacuto EVF's anamorphic ratio of 2 to do certainly level of unstretching that is good enough for rough framing, but the hdmi out framing is not correct.
Hm. Ok. So 650D or possibly 5D3.
Hopefully some test footage will be posted soon.
Fascinating developments. Exciting.
-
Hm. Ok. So 650D or possibly 5D3.
Hopefully some test footage will be posted soon.
Fascinating developments. Exciting.
Better buy 700D over 650D, because Bil only has 700D. This means that 700D always has the latest dev. LOL.
-
Right now Sandisk Extreme Pro 170 MB/s 256GB CF card is about 250 dollars, SD card is about 60 dollars, micro SD card is about 30 dollars.
Anyone here used microsd card to sd, microsd to sd to cf on 5D3? SD overclocking still performs normally?
-
ML project does not support SD-to-CF adapters. If you have troubles (and there will be!) you are on your own.
If you go for cheaper CF: Komputerbay 1066x. 128 GB variety is somehow reasonable priced. 256 not. At least around here.
-
ML project does not support SD-to-CF adapters. If you have troubles (and there will be!) you are on your own.
If you go for cheaper CF: Komputerbay 1066x. 128 GB variety is somehow reasonable priced. 256 not. At least around here.
Thanks for the quick reply, Walter. Seems not able to save money here.
-
I have added stubs for other models in first post, in case if we need them later (70D/100D/60D/600D/1300D/1200D).
DIGIC 4/4+ won't benefited currently due to limited write speed. 50D/5D2/550D lacks these function.
-
Interestingly, compared with 10 bit footage, 14 bit 2k 1x1 AR 3-2 24 fps, when shooting with auto/manual ettr, and elevating exposure one stop in MLV App, the output is very nice, similar to alexa/amira's high key footage, the noise in the dark area is not apparent. So, 14 bit is actually better than 10 bit, when using ettr, may gain one to 2 stops dr. For 10 bit shooting, better avoid ettr, because much of the information pushed to the dark side is lost and not saved in raw files.
In this term, 14 bit 4.5k 1x3 with ettr and dual iso may have a dr of 16 stops, 12 stops from the 650d raw file, 1-2 stops from ettr, 2-3 stops from dual iso. This dr is on par with the legendary alexa and amira's dr. 4.5k 1x3 raw also should be on par with the alexa/amira's 2.8k prores. The sensor size in 4.5k 1x3 mode is about 230 mm2, almost the same as 4-3's 224 mm2, although a little bit smaller than alexa/amira's super 35mm, this is good enough for news shooting, which requires large in focus zones. Imagine a lowly 650D/700D is Alexa/Amira or Red One in disguise, this is really something to talk about.
https://www.provideocoalition.com/alexa-dynamic-range-its-all-in-how-you-use-it/
https://www.newsshooter.com/2020/05/27/the-arri-alexa-is-10-years-old/
Just checked some old test footage. ON 650D, UHD 1x3 10 bit lossless has significantly lower noise level than 14 bit lossless 1920x1080 1x1 24 p in the dark area. So it is a complicated issue. Seems larger sensor size is important to lower down the noise, in addition to the data bit rate. The former one may have much more effects than the latter one.
-
yeah, i enabled both cards and spanning and i also now have continuous recording at 3616*1536 23.976 @14 bits (unless overexposed)
amazing...
bilal, you are putting the magic back into magic lantern, brother!
Hi, i might be late, how can i get this custom resolutions? i can only use the presets (3.3, 3.5k, uhd)
Oh i guess its UHD awith a small decrease in the horizontal resolution?
-
Hi, i might be late, how can i get this custom resolutions? i can only use the presets (3.3, 3.5k, uhd)
Crop mode new 2 module. Test thoroughly before real application. These are not optimized as well as Crop mode presets.
-
Crop mode new 2 module. Test thoroughly before real application. These are not optimized as well as Crop mode presets.
Oh thank you, i was trying that on a 5D3 lol
-
Oh i guess its UHD awith a small decrease in the horizontal resolution?
Correct.
on 5D3 set crop mode preset to UHD, from RAW video submenu set resolution to 4096 and Aspect Ratio to 16:9 so you can get 3840x1536 then highlight "Resolution" and use "Main Dial" or "Multi-Controller" to decrease resolution to 3616x1536.
Crop mode V2 is not related here, and that's only for 650D/700D.
-
Hi, sometimes when using "one more hack" the console shows
Is there any way i can remove the console? (not the "Show console: off" but deleting the console or maybe even just ignoring it so i can see what i'm recording without the console in front of it)
-
Hi, sometimes when using "one more hack" the console shows
Is there any way i can remove the console? (not the "Show console: off" but deleting the console or maybe even just ignoring it so i can see what i'm recording without the console in front of it)
If the console shows, it means there is a Failure somewhere. I have this sometimes too, deleting the last clip (because of corruption) and restart Camera is the best way.
Maybe you can read the failure message next time, maybe it is helpful for bug fixing.
-
Yeah, I simply can't turn off the console all time (or even only when RAW video recording). It's used mostly in every ML feature, disabling it is not a good idea at all, you may have corrupted frames while recording without realizing that which result in totally useless MLV clip.
I didn't have console showing when I used "One more hack". Could you share your settings? a steps to reproduce?
-Probably adding a little more delay (https://www.magiclantern.fm/forum/index.php?topic=25784.msg238682#msg238682)after calling "One more hack" could solve this problem. I will do it soon.
-In general: avoiding using "One more hack" could be a better idea for now, since I really don't know what is it doing (this hack actually disables some EDMAC channels activity), figuring out how to silence EDMAC channels streams without using CartridgeCancel a.k.a "One more hack" in clean way is a solution for the side effects we are having when using this hack.
-Edit: also mind share printed message in the console? are you sure it's from "One more hack"?
It could be from something else.
-
Hi, thank you, i couldnt reproduce consistently, i'm not sure its from "One more hack"
I managed to get the logs from yesterday, i'm not sure if this is helpful:
Preset: 3.5K 1:1
14bit lossless
Card Spanning on
Use SRM Memory: On
Small Hacks: Af Off
More Hacks: lvface+aewb
One more hack: On
SD Overclock: 160mhz
Dual Iso: Off
ML ASSERT:
0
at mlv_lite.c:2768 (compress_task), task compress_task
lv:1 mode:3
compress_task stack: 1ae530 [1ae5c0-1ad5c0]
0x0006A01C @ b451e0:1ae560
0x00069878 @ 6a084:1ae530
Magic Lantern version : Nightly.2022Apr07.5D3113
Mercurial changeset : 712fa0bdd45c+ (crop_rec_4k_mlv_snd_isogain_1x3_presets) tip
Built on 2022-04-07 02:25:55 UTC by Bilal@DESKTOP-7RFHEE1.
Free Memory : 213K + 2362K
When 1080p 40fps:
Presets: mv1080p 40fps
14bit lossless
Card Spanning: Off
Preferred Card: SD
Kill Global Draw: On
Use SRM Memory: On
Small Hacks: Af Off
More Hacks: lvface+aewb
One more hack: On
Recording Delay: 2s / recording time 5s
SD Overclock: 160mhz
Dual Iso: Off
ML ASSERT:
0
at mlv_lite.c:2768 (compress_task), task compress_task
lv:1 mode:3
compress_task stack: 1ae530 [1ae5c0-1ad5c0]
0x0006A01C @ b45440:1ae560
0x00069878 @ 6a084:1ae530
Magic Lantern version : Nightly.2022Apr07.5D3113
Mercurial changeset : 712fa0bdd45c+ (crop_rec_4k_mlv_snd_isogain_1x3_presets) tip
Built on 2022-04-07 02:25:55 UTC by Bilal@DESKTOP-7RFHEE1.
Free Memory : 213K + 3001K
-
Hi there,
I am awfully sorry to sound like a total bozo... but I cannot get ML to load the modules. I get only 2, namely adtg and bench.
Tried multiple times, no luck whatsoever. I am not new to ML and all crop rec releases have been working fine, including the experimental ones.
This time around I can't figure out what's wrong.
Running firmware 1.2.3
Thanks a lot, guys!
-
Updated links in the first post (https://www.magiclantern.fm/forum/index.php?topic=26443.0) for 5D3 and EOSM to Danne's downloads page.
It seems Danne added a delay after calling CartridgeCancel, please test latest Danne build for 5D3 and see if there is a first frame corruption when using "One more hack".
-
Tested briefly after adding but seemed to be working. Not sure what delay is best but added this to cartridge cancel:
if (one_more_hack)
{
void (*CartridgeCancel)() =
cam_eos_m ? 0xffa7e7d8 :
cam_5d3_113 ? 0xff17fd68 :
cam_5d3_123 ? 0xff181340 :
0;
CartridgeCancel();
msleep(40);
}
-
Scene: composed of several tree with dense green leaves, a parking lot with several cars, a gate with iron fences
Time: during the sunny noon at ISO 100
Lens: EFS lens 10-18 IS at 10 mm, F8, IS on, AF on
Camera: 5D3, ML Dann's version 20220517 1.13
Small hack: AF on
Three hacks on
Card spanning on
SD overclocking 160hz
Global draw always on
Auto ETTR on
Dual ISO off
1. 3K 1X1 preset, 1920x1920 AR 1:1 14 bit lossless, 24 fps, data stream 90 MB/s, the first several seconds orange, then always green, 1 minute recording, continuous.
2. 3.3K 1X1 preset, AR 16:9 10 bit lossless, 24 fps, data stream 110 MB/s, the first several seconds red, then always orange, 1 minute recording, continuous. 12 bit lossless is 140 MB/s and can only last for less than three seconds.
3. 3.5K 1X1 preset, AR 2.67 14 bit lossless, 24 fps, data stream 110 MB/s, the first several seconds orange, then always orange with large buffer like 15 seconds, 1 minute recording, continuous. AR 2.39 is 125 MB/s and can only last for less than 30 seconds.
4. Anamorphic 1x3, 1920x2340, 14 bit lossless, 24 fps, data stream 105 MB/s, the first several seconds orange, then always orange with large buffer like 30 seconds, 1 minute recording, continuous. Lens at 18 mm to cover the full frame.
Seems 120 MB/s is the limit for continuous recording.
-
Found another hack which appear to disable LVICV task which saves a little CPU and memory cycles, I completely don't know what this task does:
LVICV_ReleaseResource: during my tests this hack seems not very reliable (at least on my 700D, didn't make tests on 5D3), sometime I can record more frames with this hack enabled, sometime recording time becomes shorter and it's better to not use it, however card benchmarks appear to have little improvement and the improvement is constant (unlike when RAW video recording):
no hacks: only LVICV_ReleaseResource:
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FfXcYjFh%2FNo-hacks.png&hash=ffbd42b28c17f29a9c243335802557db) (https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FBP5qdg7%2FLVICV-Release-Resource.png&hash=0d7235c423bc00d797934b95edff93ce)
Around ~1.9 MB/s more, but . . but . . I was about to post benchmarks with all previous hacks with LVICV_ReleaseResource, and . . write speed was identical (huh, I remember it was about ~ 1 MB/s increase during my initial tests some days ago), anyway read first general note down below.
General notes:
-It seems there is some kind of curve for write speed improvement, once we reach higher write speeds, the effect of a new hack become lower, e.g. if you applied only LVICV_ReleaseResource hack and run benchmarks you can get ~2 MB/s improvement, but when you apply LVICV_ReleaseResource hack beside all previous hacks the gain is only ~1 MB/s (same applies for other hacks).
-My Sandisk Extreme PRO UHS-I U3 170 MB/s SDXC card version (which I made these tests (https://www.magiclantern.fm/forum/index.php?topic=26443.msg238349#msg238349) using it) is limited to ~90 MB/s maximum write speed, while other versions can go up to 98 MB/s (https://www.magiclantern.fm/forum/index.php?topic=25784.msg236947#msg236947) (@Walter Hmm was that an Sandisk card? It seems it's not (https://www.magiclantern.fm/forum/index.php?topic=26443.msg238981#msg238981)), but this card (https://www.magiclantern.fm/forum/index.php?topic=12862.msg228490#msg228490) is for sure a Sandisk card and it performs 99 MB/s write speed, same as my old 32GB Sandisk Extreme PRO 95MB/s UHS-I U3 SD card (https://www.magiclantern.fm/forum/index.php?topic=12862.msg228555#msg228555) (second photo), but that card wasn't stable for me at 240 MHz, anyway, what I am trying to say we actually can reach:
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FNYchghw%2FSandisk-Extreme-PRO-32-GB.png&hash=11ea5d383b6e3061443e606951ebc58f)
*~90MB/s write speed in LiveView! 8)
so basically 3K 3072x1308 @ 23.976 FPS at 10-bit lossless is Continuous :P
*Only when using certain versions of Sandisk Extreme PRO UHS-I U3 170 MB/s (probably 95MB/s too) cards which reach 99 MB/s in benchmarks in Play mode. I think @Levas has 95 MB/s version? and it's stable at 240 MHz unlike my 95 MB/s version, I think it's time to me to get new card (is there a way to know it would perform 99 MB/s write speed before buying it? :P).
Stubs:
0xff0d6444 700D.115
0xff0d62e0 650D.104
**Try to find them for other models**
I will include LVICV_ReleaseResource hack in my next build release for 650D/700D, to be tested.
-
while other versions can go up to 98 MB/s (https://www.magiclantern.fm/forum/index.php?topic=25784.msg236947#msg236947) (@Walter Hmm was that an Sandisk card?)
Adata Premier ONE 64GB microSDXC. UHS-II. Rated 275MB/s, V90.
-
I have added stubs for other models in first post, in case if we need them later (70D/100D/60D/600D/1300D/1200D).
DIGIC 4/4+ won't benefited currently due to limited write speed. 50D/5D2/550D lacks these function.
I think this time has come, could you make a build for 60d, I would try it myself, but I'm not a programmer)
-
SanDisk 170 mb/s sd card can only write 90 mb/s. maybe 300 mb/s card is needed for 99 mb/s write speed?
-
With these new hacks + overclocking + card spanning, 5D3.113 gives 3840x1536 14 bit semi-continously :o
Previously I could only get 12 bit for no more than 10 seconds.
I can't thank you enough!
-
Adata Premier ONE 64GB microSDXC. UHS-II. Rated 275MB/s, V90.
Okay, thanks, do you know if it switch to 48 MHz (drop to 21 MB/s) with 240 MHz overclocking after a while?
It is stable at 240 MHz?
-
SanDisk 170 mb/s sd card can only write 90 mb/s. maybe 300 mb/s card is needed for 99 mb/s write speed?
I am not sure, but there are more than one SanDisk 170 MB/s version, like:
1-SDSDXXY-128G-ANCIN --> Cameramemoryspeed.com claims it can reach up (https://www.cameramemoryspeed.com/reviews/sd-cards/sandisk-extreme-pro-170mbs-uhs-i-u3-v30-128gb-sdxc-memory-card/) to 98.643 MB/s write speed.
2-SDSDXXY-128G-GN4IN --> No idea
-
With these new hacks + overclocking + card spanning, 5D3.113 gives 3840x1536 14 bit semi-continously :o
Previously I could only get 12 bit for no more than 10 seconds.
I can't thank you enough!
Cool, have fun :)
-
Okay, thanks, do you know if it switch to 48 MHz (drop to 21 MB/s) with 240 MHz overclocking after a while?
It is stable at 240 MHz?
I have to resolve problems with card access and loosing cam's bootflag first.
-
Overclocking in video mode doesn't work well for 650D.
Photomode gives 98 MByte/s max and no fallback to 20 MByte/s. Modules bench and sds_uhs loaded.
In movie mode numbers are much lower and 240 MHz does fall back to 20 MByte/s.
Additionally loading mlv_lite will give "malloc error: buffer=16777216" during read runs.
-
Hi there,
I am awfully sorry to sound like a total bozo... but I cannot get ML to load the modules. I get only 2, namely adtg and bench.
Tried multiple times, no luck whatsoever. I am not new to ML and all crop rec releases have been working fine, including the experimental ones.
This time around I can't figure out what's wrong.
Running firmware 1.2.3
Thanks a lot, guys!
Hello,
Danne made some of modules (like crop_rec.mo/mlv_lite/mlv_snd.mo probably sd_uhs/dual_iso too) in his custom builds loaded by default and you can't unload/load them at your own, it's always loaded.
Go to "Movie" tab from ML settings and you will see RAW video and Crop mode are there (search for other modules, they will probably be in other ML tabs).
-
I think this time has come, could you make a build for 60d, I would try it myself, but I'm not a programmer)
60D card slot is limited to 21 MB/s write speed, and you can already get 21 MB/s write speed in LiveView. So the new hacks will not make any difference, unless someone get SD overclocking working on 60D.
-
With these new hacks + overclocking + card spanning, 5D3.113 gives 3840x1536 14 bit semi-continously :o
Previously I could only get 12 bit for no more than 10 seconds.
I can't thank you enough!
I'm sorry being a bit off topic but i have a question
i'm trying with overclocking, these new hacks, card spanning, killing global draw,and i cannot get 14 bit for more than 3 secs (3.5K preset, 24fps)
The scene is exposed to the right, Raw module says 168mb/s required (lossless)
Is it better underexposing by 1 or 2 stops or stick with 10bit properly exposed to the right?
I'll 3 scenes from yesterday:
-
I did some testing of my own, adding the lines from the following commits to Danne's 5d3 repo:
8a57a24: https://bitbucket.org/Dannephoto/magic-lantern_dannephoto_git/commits/8a57a244b767337904f18f3c1bcf1199c3a3ac24
61c2a5a: https://bitbucket.org/Dannephoto/magic-lantern_dannephoto_git/commits/61c2a5a38fedc273156882850ebe5ce302cc858b
LvFace+AEWB nets a realworld gain of 7MB/s
Cartridge cancel has No effect on real world write speed.
This of course only applies to 5D3 1.23
-
I tested on my lexar 1667x using 240mhz setting same result w/wo two more hack
write 96.7 mb/s
read 102.3 mb/s
preset 4K 1x3 12bit continues recording
btw, bilal.. what is the best setting for sandisk extreme pro 170mb/s?
thanks for the hack speed.
-
I have more hacks and 240Mhz included in my build already? What's the difference here?
-
lexar has more write speed than sandisk extreme but less read speed.
I mean using 1+2 hack on lexar has no different result..
-
I was more curious about why dpjpandone added code already in place :).
-
I was more curious about why dpjpandone added code already in place :).
I worded that poorly. What I meant was I added the changes
FROM: (Danne's) committs
TO: MY (based on mainline crop_rec) mlv_lite
-
btw, bilal.. what is the best setting for sandisk extreme pro 170mb/s?
What do you mean by "best setting"? What are you looking for?
thanks for the hack speed.
No problem, have fun :)
-
I worded that poorly. What I meant was I added the changes
FROM: (Danne's) committs
TO: MY (based on mainline crop_rec) mlv_lite
I see. Do you see any difference in speed/performance here between the two?
-
What do you mean by "best setting"? What are you looking for?
I mean is it just use 1+2 hack and 240mhz only or anything else need for speed..?
somehow the speed is drop sometimes when I benchmark again..
-
I mean is it just use 1+2 hack and 240mhz only or anything else need for speed..?
somehow the speed is drop sometimes when I benchmark again..
easy to test. forget about card benchmark it's meaningless. set your resolution to something higher than you can record continuously. record a short clip. check raw menu for sustained bitrate. add a hack. test again. add another hack, test again, keep going back to raw menu to check the write speed that was achieved during previous recording. use the settings that produced the highest write speed during recording
-
I see. Do you see any difference in speed/performance here between the two?
LV+AEWB adds 7MB/s
Carteridge makes no difference
I should note that this is 5D3 tested with Sandisk Extreme Pro 170MB/s SD card @240 MHz. Best record speed was around 88MB/s. closer to 81MB/s without LVFace+AEWB. These are real world recording speeds.
Speeds with my CF card are about 10MB/s lower across the board, the CF I own is the bottleneck in that case so no reason to test CF. No desire to purchase faster CF since SD has enough bandwith for my use.
-
I mean is it just use 1+2 hack and 240mhz only or anything else need for speed..?
For me, I get the best write speed when all hacks are enabled.
Also, check this article (https://www.magiclantern.fm/forum/index.php?topic=26521.msg239231#msg239231), also mentinoed in first post (https://www.magiclantern.fm/forum/index.php?topic=25784.msg231049#msg231049) in my 650D/700D thread:
-Looking for more recording times?
-Check Image quality and its effect on memory (more RAM 4 free) (https://www.magiclantern.fm/forum/index.php?topic=26521.msg239231#msg239231).
somehow the speed is drop sometimes when I benchmark again..
How do you do your benchmarks? like in Play mode or Video mode?
Do you change Camera or ML settings among benchmark passes?
First step to do if you have speed drops is to perform a "low level format" in camera from Canon menu, then run benchmarks as many time as you want in the same mode/settings . . benchmarks should give very similar results everytime.
-
Carteridge makes no difference
Nope, it does make a difference . . at least my benchmarks prove that.
Best record speed was around 88MB/s. closer to 81MB/s without LVFace+AEWB. These are real world recording speeds.
How did you make your calculations?
-
For me, I get the best write speed when all hacks are enabled.
Also, check this article (https://www.magiclantern.fm/forum/index.php?topic=26521.msg239231#msg239231), also mentinoed in first post (https://www.magiclantern.fm/forum/index.php?topic=25784.msg231049#msg231049) in my 650D/700D thread:
noted..
How do you do your benchmarks? like in Play mode or Video mode?
Do you change Camera or ML settings among benchmark passes?
I benchmark using video mode..
I benchmark first then taking video 10s each with changing ML setting like dualiso, crop preset and iso when I feel the speed drop I check benchmark again.
First step to do if you have speed drops is to perform a "low level format" in camera from Canon menu, then run benchmarks as many time as you want in the same mode/settings . . benchmarks should give very similar results everytime.
oh..ok thanks.
I'll try to low level format and enable all hack then.
-
easy to test. forget about card benchmark it's meaningless. set your resolution to something higher than you can record continuously. record a short clip. check raw menu for sustained bitrate. add a hack. test again. add another hack, test again, keep going back to raw menu to check the write speed that was achieved during previous recording. use the settings that produced the highest write speed during recording
ok thanks.
-
I benchmark first then taking video 10s each with changing ML setting like dualiso, crop preset and iso when I feel the speed drop I check benchmark again.
Write speed is affected by many factors like resolution and FPS, it varies from video mode to another, also from crop preset to another.
Higher resolution and FPS means reducded write speed compared to less resolution preset or lower FPS. Anyway the hacks help in all kind of settings.
You shouldn't compare write speed in a preset to another, but compare write speed in one preset like this: once with hacks disabled and once with hacks enabled.
Also, all hacks got disabled if you are not recording, benchmarks in video mode will always show write speed without the hacks.
-
Write speed is affected by many factors like resolution and FPS, it varies from video mode to another, also from crop preset to another.
Higher resolution and FPS means reducded write speed compared to less resolution preset or lower FPS. Anyway the hacks help in all kind of settings.
You shouldn't compare write speed in a preset to another, but compare write speed in one preset like this: once with hacks disabled and once with hacks enabled.
Also, all hacks got disabled if you are not recording, benchmarks in video mode will always show write speed without the hacks.
thanks bilal.
I use play mode and the test look stable now
with all hack enable I can record 1440 1:1 preset with longer duration
(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fi.ibb.co%2FmhmqmtG%2FWhats-App-Image-2023-01-26-at-13-24-24.jpg&hash=aab04d00161578a0fd66187b646da2e5)
-
Nope, it does make a difference . . at least my benchmarks prove that.
How did you make your calculations?
5D3 Sandisk Extreme Pro 170MB/s SD card @240 MHz
Real world RECORDING (not benchmark) speeds (global draw enabled, but no histogram/zebras or other performance sucking overlays)
Small hacks = 81MB/s
Small hacks +LVFACE/AEWB = 88MB/s
Small hacks +LVFACE/AEWB + Cartridge cancel = 88MB/s
what are your actual sustained RECORDING speeds?
-
Small hacks = 81MB/s
Small hacks +LVFACE/AEWB = 88MB/s
Small hacks +LVFACE/AEWB + Cartridge cancel = 88MB/s
And what about. Small hacks + LVFACE (without AEWB)?
-
And what about. Small hacks + LVFACE (without AEWB)?
it's less without AEWB. Pretty close to just small hacks. AEWB nets the massive 7 MB/s improvement
It's a pretty huge sacrifice to lose shutter fine tuning, but this hack makes it possible to record continuous 12-bit lossless 3k 2.39 to SD card at very high ISO's which is the most I will ever ask the camera to do in real life. I have no use for broken preview modes. 3.5k with a realtime 5x preview is perfect for extreme closeups or macro shots, I do the rest of my work in 1080p and the 5D3 is DAMN SHARP and rolling shutter is acceptable.
-
@dpjpandone
Your test isn't accurate, beside it misses some infos:
1. Run benchmarks in Play mode at 240 MHz, reported write speed? if SD card already reached its maximum write speed in LiveView (with small and LVFACE/AEWB hacks), you won't gain anything more in LiveView.
2. Your camera and ML settings?
3. Try this test: turn on Small hacks, turn off "LVFACE/AEWB" then hit recording button, reported write speed?, now turn on "Cartridge cancel" (keep LVFACE/AEWB off, and small hacks on), reported write speed?
4. Reported write speed in LiveView (from RAW video) isn't always accurate, buffer size will have an impact too, especially on 5D3, you need to record long clips at same settings (FPS, resolution, exposure and a static scene and s if you are using lossless, and it would be better to use uncompressed RAW), also record a few clips each time, make the calculations then average the results.
Real world RECORDING (not benchmark) speeds ..
Yes, I said "at least" benchmarks prove that, but in reality I can see an improvement in recording times and write speed also in actual recording, especially on 700D. 5D3 does have an improvement too.
Quick tests on 700D, 240 MHz, 1736x1160, 14-bit uncompressed, 23.976 FPS, Global Draw off, mlv_snd on, "lvface and aewb" are disabled reported required write speed 80.5 MB/s:
-Small hacks enabled:
Clip 1: 177 Frames
Clip 2: 198 Frames
Clip 3: 189 Frames
Clip 4: 185 Frames
Clip 5: 191 Frames
Average: 188 Frames, 7.8 Seconds, reported write speed up to ~67 MB/s
-Small hacks enabled + CartridgeCancel:
Clip 1: 211 Frames
Clip 2: 378 Frames
Clip 3: 377 Frames
Clip 4: 243 Frames
Clip 5: 187 Frames
Clip 6: 375 Frames
Average: 295 Frames, 12.2 Seconds, reported write speed up to ~74 MB/s
5D3 should give similar results (I did some tests in past).
-Last note:
You can see the most gain for each hack once that hack is enabled alone, e.g. if you enable small hacks you will see *large* write speed improvement compared to if small hacks disabled, if you turned off small hacks, and only enable lvface and aewb, you will see the most gain for these two hacks, but if you enable small hacks + lvface and aewb, the total gain will be reduced:
for example:
if you gained 7 MB/s with small hacks alone
if you gained 7 MB/s with more hacks alone (lvface and aewb)
the total gain won't be 14 MB/s if both were enabled, but something less than that, like 11-12 MB/s . . this applies to "CartridgeCancel" too. There is some kind of curve here.
-
And what about. Small hacks + LVFACE (without AEWB)?
aewb task is the most CPU hungry task on 700D, on 5D3 it takes good amount of CPU too, suspending aweb has nice positive impact on write speed.
AFAIK, currently Shutter fine-tuning is depending on aewb task (when aewb task get disabled, it break this feature), more likely it can be fixed if we override shutter speed registers directly from ADTG patch . . I didn't test this theroy yet.
-
I forget, Bilal - did you try lowering priority on these tasks, rather than disabling them? That might allow them to work, presumably at a lower frequency, while still saving quite a lot of CPU. Might be a useful tradeoff; I'd guess things like shutter fine tuning would update less frequently but would still work. Presumably you'd gain less write speed, but hopefully still some?
-
@names_are_hard
Yes, a while ago I did some tests, and results were bad, *I could control tasks priority using this function on 700D 0xff35654c:
Lowering priority to a medium amount resulted in worse write speed and probably corrupted frames in some tasks, lowering priority to maximum or very high values --> Camera crash
My theory is other tasks like LiveView ones will still wait for other tasks to do its job, resulting in delays (which mean lower write speed, corrupted frames), if priority was too low, other tasks never get response from the lowered priority task, so it crashes the camera.
..rather than disabling them?
The tasks themselves never get disabled on Canon task manager, it got disabled internally, maybe it does something like "hey other tasks, work without me", it's probably set a flag, or return a response sayes everything work fine to other tasks/function, beside it stop doing its job.
*I couldn't change priorities for all tasks on real hardware using that function (well, I could change priorities for the tasks I needed), on QEMU the same function could change priorities for all tasks.
-
-Last note:
You can see the most gain for each hack once that hack is enabled alone, e.g. if you enable small hacks you will see *large* write speed improvement compared to if small hacks disabled, if you turned off small hacks, and only enable lvface and aewb, you will see the most gain for these two hacks, but if you enable small hacks + lvface and aewb, the total gain will be reduced:
this makes sense, I'll try it without the other hacks and let you know
-
Yes, a while ago I did some tests, and results were bad, *I could control tasks priority using this function on 700D 0xff35654c:
Lowering priority to a medium amount resulted in worse write speed and probably corrupted frames in some tasks, lowering priority to maximum or very high values --> Camera crash
Ah, good, you tried it :) A shame it didn't work properly. Your guess that other things are waiting on the results makes sense to me from those symptoms. Maybe improvements could be made, but they don't sound the easy kind.
-
Good thing bilal also solved 240Mhz sd patch solving most overhead issues even without the aewb hack :).
-
Good thing bilal also solved 240Mhz sd patch solving most overhead issues even without the aewb hack :).
Truly amazing
-
I was putting it back to test again. why is it complaining about this:
mlv_lite.c:2170:9: warning: initialization of 'void (*)()' from 'unsigned int' makes pointer from integer without a cast [-Wint-conversion]
2170 | cam_eos_m ? 0xff2606f4 :
| ^~~~~~~~~
mlv_lite.c:2176:9: warning: initialization of 'void (*)()' from 'unsigned int' makes pointer from integer without a cast [-Wint-conversion]
2176 | cam_eos_m ? 0xff177ff8 :
| ^~~~~~~~~
mlv_lite.c:2196:9: warning: initialization of 'void (*)()' from 'unsigned int' makes pointer from integer without a cast [-Wint-conversion]
2196 | cam_eos_m ? 0xffa7e7d8 :
| ^~~~~~~~~
void hack_liveview_more()
{
if (more_hacks && shamem_read(0xc0f383d4) != 0x4f0010) /* excludes mcm mode on eosm */
{
void (*aewbSuspend)() =
cam_eos_m ? 0xff2606f4 :
cam_5d3_113 ? 0xff23bc60 :
cam_5d3_123 ? 0xff23ff10 :
0;
void (*lvfaceEnd)() =
cam_eos_m ? 0xff177ff8 :
cam_5d3_113 ? 0xff16d77c :
cam_5d3_123 ? 0xff16e318 :
0;
lvfaceEnd();
if (more_hacks == 2)
{
aewbSuspend();
}
}
if (one_more_hack)
{
void (*CartridgeCancel)() =
cam_eos_m ? 0xffa7e7d8 :
cam_5d3_113 ? 0xff17fd68 :
cam_5d3_123 ? 0xff181340 :
0;
CartridgeCancel();
msleep(40);
}
}
is this compiler just being picky or is there a problem?
-
I have the same. Some unclean code which needs some polishing I guess.
-
I have the same. Some unclean code which needs some polishing I guess.
should we put those lines in the stubs file instead?
-
We can add the addresses like this commit (https://github.com/bilalfakhouri/magiclantern_hg_02/commit/cd8ab0b42cc5d5087cffe1362e7299957502b33b), under:
static unsigned int raw_rec_init()
if (is_camera("5D3", "1.1.3"))
{
lvfaceEnd = (void *) 0xFF16D77C;
aewbSuspend = (void *) 0xFF23BC60;
CartridgeCancel = (void *) 0xFF17FD68;
}
That commit is cleaner implementation than the one in our current builds.
Edit: that commit has some "spacing" issue, a coder error :P, it doesn't affect the code of course, but how it looks like. Will fix it later.
Thanks names_are_hard for mentioned this :)
-
Nice to see your code up there bilal online 8).
-
We can add the addresses like this commit (https://github.com/bilalfakhouri/magiclantern_hg_02/commit/cd8ab0b42cc5d5087cffe1362e7299957502b33b), under:
if (is_camera("5D3", "1.1.3"))
{
lvfaceEnd = (void *) 0xFF16D77C;
aewbSuspend = (void *) 0xFF23BC60;
CartridgeCancel = (void *) 0xFF17FD68;
}
Are these addresses function pointers? If so, you shouldn't really cast to void *. This will hide the compiler warning without fixing the problem.
How many params do these functions take? Do they return a value? If they don't meet standard ARM calling conventions this could corrupt program state and maybe cause crashes.
These would likely be better as stubs. That way you could remove the per cam code from the module, and just call the stubs - same name for all cams.
-
Is this source tree from your gitfix @names_are_hard? I notice commits are directly out into the original branch. Should we continue forking code instead? Are these cvamges to be pushed to your source again or is everyone keeps his own codebase?
-
Nobody should be using magiclantern_hg_02 and I don't know why Bilal is working from that repo :) I made that one strictly as an archive, it keeps all the history of the hg repo. I will never take changes back into https://github.com/reticulatedpines/magiclantern_hg_02
This is where I do work: https://github.com/reticulatedpines/magiclantern_simplified
That repo, however, was made for Digic 6, 7, 8 work. Because I didn't understand the branch model for official ML (still don't!), I took the branches I needed, since there were several hundred open branches. That didn't include crop_rec. I later added crop_rec experimentally as a branch, but I believe it needs work before it can be integrated with the main code. Bilal tells me it causes problems with Digic 4 cams. I want my repo to only have one long-lived branch. I think nobody really wants all these forks and special builds from different places, it's confusing.
So, I think somebody needs to fix the problems crop_rec branch has on digic 4 cams, but I don't have any of those cams to test on.
-
Thanks for info here.
Maybe ironing out 10 most used branches personally and start building git tree from there.
It is still possible to keep all hg style but more for source access I guess.
-
My repo is based on unified and has merged at least these branches: qemu, digic6-dumper, lua_fix. Later, I split qemu out into its own repo.
I actively don't want to keep all of the branches, it was impossible to understand what they were for. Code that is good should be integrated, code that is not used should be removed.
If there are branches which are useful, I can try to integrate them, but as noted, I don't have the ability to test on digic 4 or 5 cams. I don't want to break any cams. Some things can be tested in Qemu, some things can't. I want to integrate good code, but I won't take code that breaks things. I will put in a lot of work to fix things if I can see it's worthwhile (lua_fix merge was about 40k lines of diff and took several days and a lot of testing).
Also, somebody would need to tell me what the useful branches are, and what they're for. There are literally hundreds of open branches on Heptapod.
-
These would likely be better as stubs. That way you could remove the per cam code from the module, and just call the stubs - same name for all cams.
I'm trying to learn how to do this properly. Can you please check my work?
The code from TheBilal was:
if (is_camera("5D3", "1.2.3"))
{
lvfaceEnd = (void *) 0xFF16E318;
aewbSuspend = (void *) 0xFF23FF10;
CartridgeCancel = (void *) 0xFF181340;
more_hacks_are_supported = 1;
CartridgeCancel_works = 1;
The first step I think is to add this to Stubs.s in 5D3.123:
/** LiveView Hacks For Write Speed Improvement **/
///NSTUB(0xFF16E318, lvfaceEnd)
///NSTUB(0xFF23FF10, aewbSuspend)
///NSTUB(0xFF181340, CartridgeCancel)
now when we get to:
CartridgeCancel_works = 1; should this go in Features.h ?
like this?:
#define FEATURE_CARTRIDGE_CANCEL// write speed improvement in LiveView
#define FEATURE_MORE_HACKS// write speed improvement in LiveView
Let me stop here because I dont know if it's ok to define a feature that is dependent on a module?
-
I can't check it thoroughly because I don't have a 5D3 and I don't know what precise code you're working from. I can give some advice.
Firstly, modules are built outside of the context of any individual cam. This is because modules are supposed to be portable: people can copy them from one card to another in a different cam and they're supposed to work. TCC code on the cam handles loading modules and looking up symbols by name. This is the way that modules find stubs. If a symbol doesn't exist, the user will see an error and the module won't load (but ML won't crash, it's more like a warning than a real error).
If you define something in features.h for a cam, I think it won't be visible to the module during the build. Even if it is, it won't work properly if you copy the module and use it with a different cam, so this isn't a correct approach.
I was suggesting that *things which are functions* could be moved to stubs. I haven't looked at the variables like more_hacks_are_supported, so I don't know what these do or what the best way to handle them is.
You should be able to test your ideas in qemu. First get the existing code working and test it emulates this far (should do I think). Then make changes and see if you broke anything.
-
I can't check it thoroughly because I don't have a 5D3 and I don't know what precise code you're working from. I can give some advice.
Not asking you to test it, just to tell me if I'm doing stubs wrong.
If you define something in features.h for a cam, I think it won't be visible to the module during the build. Even if it is, it won't work properly if you copy the module and use it with a different cam, so this isn't a correct approach.
This is helpful. On second glance I can't find an example of a module calling ifdef(feature xyz)
I was suggesting that *things which are functions* could be moved to stubs. I haven't looked at the variables like more_hacks_are_supported, so I don't know what these do or what the best way to handle them is.
more_hacks_are_supported is basically just to hide the option from the menu in cams that don't support. Is there a more elegant way to accomplish this?
-
I suppose it depends what you mean by "doing stubs wrong" :) In the module code, where it's just an address, I haven't checked how it's used. In a stub context, it will be treated as a function pointer according to the definition of NSTUB (or ARM32_FN / THUMB_FN if you use those). Is it appropriate to treat these addresses in that way? That depends how the module uses them. In the exact text you gave, you put them in as comments, which will do nothing (and the symbol won't get exported, so the modules won't find it).
more_hacks_are_supported is basically just to hide the option from the menu in cams that don't support. Is there a more elegant way to accomplish this?
Probably, but that's a bigger question than you might realise. I think the intention when ML added lots of supported models was that they'd all get all the features eventually. Later on (I guess) as you've found, FEATURE and CONFIG limit or specify features, but that doesn't work well with modules. Modules are *supposed* to be cam independent, but actually this was never true, there were some edge cases that became apparent when we worked more on modern cams and found that some structs and other internals had changed enough that some assumptions around how modules worked failed.
So, what's an elegant way to let modules behave the right way on a range of cams? My personal feeling is modules could, instead of doing this:
if (is_camera("5D3", "1.2.3"))
{
screen_x = 0x0101; screen_y = 0x0202;
}
else if { // many other cameras omitted }
Do something like this:
get_screen_x_y(screen) // screen is a struct with .x and .y members
That is: cleanly separate modules from ML code, so they can only work via exported functions. Modules ask the cam what the right values are for that model. No hard-coding values inside modules.
So in your specific example, create a stub for *all* cams maybe called is_more_hacks_supported() (this is a bad name, but you get the idea). This would probably default to returning false, and be overridden by cams that did have support. Then the module code is greatly simplified - no per cam checks, but something like this:
more_hacks_supported = is_more_hacks_supported();
Is this the best way to go? That's harder to say. It would increase the size of the ML binary, while reducing the size of modules. Size constraints are a real concern on some cams.
-
Is this the best way to go? That's harder to say. It would increase the size of the ML binary, while reducing the size of modules. Size constraints are a real concern on some cams.
I have created a new post in General Development in order to keep this thread on topic:
https://www.magiclantern.fm/forum/index.php?topic=26779.new#new
-
Are these addresses function pointers? If so, you shouldn't really cast to void *. This will hide the compiler warning without fixing the problem.
How many params do these functions take? Do they return a value? If they don't meet standard ARM calling conventions this could corrupt program state and maybe cause crashes.
...
I wasn't aware of these, thanks for mentioning them, will look into it later.
Yes, I think all of them return value, what should I do in this case?
Also it seems lvfaceEnd and aewbSuspend take values, but not quite sure, but might be decompilation error in Ghidra, how to make sure?
I used "(void *)" blindly, I saw a1ex used it in sd_uhs (https://foss.heptapod.net/magic-lantern/magic-lantern/-/blob/branch/sd_uhs/modules/sd_uhs/sd_uhs.c)for SD_ReConfiguration function, I just reused it and didn't notice problems . .
-
Nobody should be using magiclantern_hg_02 and I don't know why Bilal is working from that repo :) I made that one strictly as an archive, it keeps all the history of the hg repo. I will never take changes back into https://github.com/reticulatedpines/magiclantern_hg_02
I used it because I wanted a github solution from official hg repo which include all history beside it's a repo that well tested (on DIGIC 5), I didn't want to work on "magiclantern_simplified" because it has a lot of changes, and it still not well tested on DIGIC 5, I just didn't want to have some random or hidden surprises and spend time on it . . this thing is temporarily, my final goal is to port everything back in one branch and repo like magiclantern_simplified of course.
So, I think somebody needs to fix the problems crop_rec branch has on digic 4 cams, but I don't have any of those cams to test on.
Working on DIGIC 4 and give them crop_rec support is one of my goals, but it's not the highest priority for me currently . .
-
Yes, I think all of them return value, what should I do in this case?
Also it seems lvfaceEnd and aewbSuspend take values, but not quite sure, but might be decompilation error in Ghidra, how to make sure?
I used "(void *)" blindly, I saw a1ex used it in sd_uhs (https://foss.heptapod.net/magic-lantern/magic-lantern/-/blob/branch/sd_uhs/modules/sd_uhs/sd_uhs.c)for SD_ReConfiguration function, I just reused it and didn't notice problems . .
Here's the definition in that case:
static int (*SD_ReConfiguration)() = 0;
That is, SD_ReConfiguration is a function pointer to a function that takes no arguments (I think? I didn't check what the implied arguments are if you leave that empty), and returns an int. It is initialised to untyped 0, which is probably not ideal (does it give a compile error?).
Taking values is okay, the concern is potential conflict between the calling convention you declare (perhaps implicitly) in ML code, and the calling convention used by the external function. ARM has a standard calling convention: https://stackoverflow.com/questions/261419/what-registers-to-save-in-the-arm-c-calling-convention. Compilers will normally generate code according to those rules, but they don't have to, and it is possible to override the compiler with e.g. pragmas. Certainly, some Canon code doesn't use this convention.
Let's imagine you have some generated ML code that wants to call a Canon function you've named "do_stuff()", and you've told ML uses standard ARM calling convention. This means the compiler will generate assembly which assumes the following rules are true (and other rules, this is a specific example):
r4-r8 are callee-save registers
r9 might be a callee-save register or not (on some variants of AAPCS it is a special register)
r10-r11 are callee-save registers
"Callee-save" means the caller expects those registers will not be changed by the function call. This why if you look at the disassembly in most cases you'll see them being saved at the start of a function and restored at the end.
Therefore, the compiler will assume that the values in some variables, etc, will never be changed before and after the call. But if the Canon function is unusual, those can change. If you don't tell ML this is one of those functions, this kind of thing can happen:
some_magiclantern_variable = 0; // the compiler *might* choose to put this in r4
some_canon_function(); // in C, this function cannot change your variable...
if (some_magiclantern_variable != 0)
// this should never happen, let's crash!
assert(-1); // but in asm, it certainly can, by changing the content of r4 and returning, and you assert here
In that code you'd expect the assert to never trigger. But it can if conditions are right. There are other edge cases. Some functions don't return. Some functions expect the return address is in register you're passing to it. Some expect they can return to your saved return address. This doesn't hurt you very often, but if it does it's really confusing.
So, you need to make sure that what you tell ML about Canon functions is correct. Most Canon functions use standard ARM calling convention, which should work with the defaults. Some do not and you should confirm this before using them. You can then instruct the compiler to do the right thing, e.g. in dryos.h:
extern void __attribute__((noreturn)) cstart(void);
-
I used it because I wanted a github solution from official hg repo which include all history beside it's a repo that well tested (on DIGIC 5), I didn't want to work on "magiclantern_simplified" because it has a lot of changes, and it still not well tested on DIGIC 5, I just didn't want to have some random or hidden surprises and spend time on it . . this thing is temporarily, my final goal is to port everything back in one branch and repo like magiclantern_simplified of course.
Working on DIGIC 4 and give them crop_rec support is one of my goals, but it's not the highest priority for me currently . .
Makes sense. I wasn't saying it was wrong of you to use it, just that I didn't know your reasons :) It will make your future pain around porting higher, of course.
I don't require crop_rec to give Digic 4 cams crop_rec ability in order to take that code. I require those cams to be no worse than before. If they simply do nothing with crop_rec stuff that's fine by me. If we can restrict them with a feature flag or similar, that's acceptable. Is it possible to define what work needs to be done to make this branch possible to merge? Defined so that it is possible to know how to test if the conditions are met. What currently happens on digic 4 and 5 cams? What problems exist?
I'd really like to integrate the code that is getting used. I have multiple reasons:
- it's cool code that enables cool features!
- having one repo that everyone can use is better than 6 repos and everyone has to wonder which is the right one for their camera, etc
- if people are using old cams with my repo I have more confidence I haven't broken old cams while adding support for new ones
The last point has some caveats: if people are using my repo on old cams, I'll want some more tests first! It's had some limited testing on old cams and no new problems or bugs reported so far.