HA!!! I guess Alex is already working on this. From 500d stub FA_GetJpegBuffForLV jpeg stream address 0x42004070, FA_GetJpegSizeForLV size of buffer 0x41349. I guess will we be getting mpeg 422 pretty soon.
Quote from: Chucho on September 11, 2012, 03:40:07 AM
HA!!! I guess Alex is already working on this. From 500d stub FA_GetJpegBuffForLV jpeg stream address 0x42004070, FA_GetJpegSizeForLV size of buffer 0x41349. I guess will we be getting mpeg 422 pretty soon.
:o
Here is hoping... 2k at 4:2:2 with no line skip. I doubt data rate can support much more.
Quote from: 1% on September 11, 2012, 04:14:58 AM
Here is hoping... 2k at 4:2:2 with no line skip. I doubt data rate can support much more.
All of this at once? Wow.
4:2:2 already being thrown away. 2k is just next size up. If the frames can compress < card rate should be possible. Will probably need to be zoomed to not have line skip. It was probably the only way to fit 20MP sensor in <3MP video.
The h.264 are not even true Full HD there upsize. The live jpeg stream from the 500d is 928x616 looks as sharp as the h.264.
Aren't the other cameras a little bit bigger, I saw sizes like 1600 something from logs of 5d2. Either way, it is what it is. 928x616 can become 1920x1080 easier on a PC than in camera.
Can you already dump stream from 500D? Would like to try...
T2i / 550d is 1056x704 when not recording, when recording movie silent pic is 1700xwhatever but quality is not as sharp, looks uprezzed, comparing 4:2:2 1056x704 to MOV shows MOV is soft too but that's no secret I guess, silent pic is not exactly new.
Agree would be interesting to get stream unuprezzed and do it on the PC after.
Will a bicubic upscale in PC improve upon Camera aliasing? Or just soften the aliasing?
In photo LV, my silent pics are 2k. In Movie mode they are only 1056x704.. while recording 1680x945. Should find a way to see if they are all the same pic uprezzed. Otherwise movie mode needs to not be in movie mode. Also just saw a 1728x972, not sure where that one came from... maybe dzoom/crop?
ha ha that's what my thinking was looking at the uprezz in video mode, if silent pics are bigger in photo mode, then phot mode could be the new video mode. :-)
Wonder what fps can be sustained with .422's even at Simple in movie mode and why so many variations in rez?
Please find here the silent pic sizes: http://bitbucket.org/hudson/magic-lantern/src/tip/src/vram.c#cl-261
This reminds me that I actually have to fix the silent pic sizes....
Why silent pics have these stupid sizes? I don't understand what could be the motivation behind this.
Crop mode in video is almost HD.
Funny thing is, I got several 2k pic in photo mode somehow today and now I can't reproduce... wtf happened. It was simple silent pics. I thought it was normal and I deleted them but from that file its not.
I am trying to run recovery on the card to get them back and upload here.
Success! It was converted with 422 to png but recovery pegs them as jpeg for some reason.
http://www.qfpost.com/file/d?g=oaiFA61Xu (http://www.qfpost.com/file/d?g=oaiFA61Xu)
Don't laugh at my messy studio :)
*still can't reproduce... but saw the possibilities of whats working and it looks better than video we get now by far.
1% no I haven't been able to produce a "stream" yet. And yes other camera buffer size are bigger like the 5d2 1120x752. All I can say is grading a 24 bit depth video is way cleaner than a 8 bit :)
Edit; I get it now jpeg are RGB 8-bit+8-bit+8-bit = 24-bit
Edit 2; jpeg are Y (Subsamp 1x1), Cb (Subsamp 2x1), Cr (Subsamp 2x1) 4:2:2 not RGB
A good test would be with noisy high ISO footage. Be interesting to see what effect grading such poor pictures would be.
I think 600D crop size is the biggest and closest to HD out of all of them. Next to 5DIII of course which is completely different.
So there is an MJPEG decoder in camera already? For the image player?
FF2F10D8: 'PlayBack\\MjpegDecRotatePath.c'
FA_GetJpegBuffForLV seems to be null in the 600d, going to start dumping VRAM and look for the magic jpeg numbers FF D8 FF. 5d3 has the same problem but with the 5d3 you still can make a movie with uncompress YUV 422 files with the right CF card, SD cards are not fast enough:(
Hopefully its somewhere.
FF0A1F80 FA_LvJpegCheck
These were null?:
2 ; *'FA_GetJpegSizeForLV'
FF56DB6C: ff1115e8 ; 0xff1115e8: pointer to 0xe51f01f4
FF56DB70: ff72d496 ; *'FA_GetJpegBufForLV'
FF56DB74: ff1115dc ; 0xff1115dc: pointer to 0xe51f01e8
I read from those registers and get "deadbeaf" .... assholes!
I dumped ram (~268mb) and found FF D8 FF in serveral spots. How do you dump vram?
From looking at 40D thread... maybe LV jpeg as to be started? Esp on newer cameras.
NSTUB(0xFF0A161C, str:lv_save_raw_lv_af_raw_lv_start)
has lv_save_raw + lv_start
FA_StartLvTestImage
Has:
FA_StartLvTestImage+20: 'lv_save_raw'
FA_StartLvTestImage+32: 'lv_af_raw'
FA_StartLvTestImage+40: 'lv_old_start'
from log in the other thread are these stream addresses?
574C 40908294
5750 4A000090
Also:
FA_LvJpegCheck+36: call('lv_no_flicker', *(arg0), 'FA_LvJpegCheck %d')
Another thought..... Maybe the unknown path/mode from http://magiclantern.wikia.com/wiki/Register_Map is the unused LV jpeg?
The 600D looks similar to 5D3 and 60D... where MJPEG doesn't work at all :(
If it's somewhere, it has to be in EDMAC registers.
Has anyone tried setting the registers to the unused path(s) and then reading that jpeg register?
The flicker was mentioned in the check jpeg function.
0x10 - Flicker
Also this:
0xC0F0501C [32] WREDMAC16 (would be WREDMAC7, but that seems unused)
0xC0F05020 [32] RDEDMAC0 (would be WREDMAC7, but that seems unused)
How do these regs look on other cameras? I don't have nstub addresses for lv old or lv no flicker so I can't try to call them. I can try calling the jpeg check while outputing that reg to screen.
Are you sure? 0xFF111928 seems like an interesting function to analyze on the 600D
as it uses B:/DCIM/LV%06d.jpg
EDMACs are camera-specific, but usually they are just reordered.
5D2:
c0f04000: 1
c0f04004: 20000000
c0f04008: 4000080 <-- HD buffer
c0f04010: 2a70800
c0f04100: 4
c0f04108: 1c414000 <-- ?! 720x680 image
c0f04110: 27f05a0
c0f04200: 1
c0f04204: 20000000
c0f04208: 1fab73e0 <--
c0f04210: e00020
c0f04400: 4
c0f04408: 2004070 <-- jpeg
c0f04410: fff0200
c0f04500: 4
c0f04504: 20000000
c0f04508: 10000080 <-- ?
c0f04510: 104dc
c0f04600: 4
c0f04604: 300
c0f04608: 1faa8040 <-- luma, reverse endian, 320x200?
c0f0460c: d
c0f04610: 2f0
c0f04614: 1000
c0f04800: 1
c0f04804: 40010000
c0f04808: 4346f8 <--
c0f04810: 7520020
c0f04900: 1
c0f04904: 40010000
c0f04908: 4a4778 <--
c0f04910: 13c0020
c0f04b00: 4
c0f04b08: 1c414000 <-- 720x680
c0f04b10: 27f05a0
c0f04c00: 4
c0f04c08: 1faa8040 <--
c0f04c0c: 1000
c0f04c14: 1000
c0f04d00: 4
c0f04d08: 10000080 <--
c0f04d0c: 540003
c0f04d10: 70200
c0f04d14: 70200
c0f04d18: 600
c0f04d1c: fffc800
c0f04d20: 600
c0f04d24: fffc800
c0f04e00: 104
c0f04e04: 80010000
c0f04e08: 700000 <--
c0f04e10: 700000
c0f04e20: 100000
c0f04e28: 100000
c0f04e30: 100000
c0f04e34: 7
c0f04f10: 1
c0f26100: 4
c0f26104: 20000080
c0f26108: 1c4f5000 <--
c0f26110: 27f0276
c0f26200: 1
c0f26204: 20000080
c0f26208: 1b07800 <-- LV buf
c0f26210: 1a805a0
60D:
c0f04000: 1
c0f04004: 20000000
c0f04008: 1c717c00 <- WriteEDmacWbInteg
c0f04010: ef0020
c0f04200: 1
c0f04204: 20000000
c0f04208: 6000080 <- HD buffer, WriteEDmacYuv
c0f04210: 2bf0840
c0f04300: 1
c0f04304: 20000000
c0f04308: 1c307800 <- LV buffer, WriteEDmacVram
c0f04310: 1df05a0
c0f04400: 4
c0f04408: 2000070 <- WriteEDmacPackMem
c0f04410: fff0224
c0f04500: 4
c0f04508: 1c73fc00 <- WriteEDmacFenYuv
c0f04510: 27f05a0
c0f04600: 4
c0f04604: 300
c0f04608: 1c83b8e0 <- WriteEDmacFen_B
c0f0460c: d
c0f04610: 2f0
c0f04614: 1000
c0f04800: 1
c0f04804: 40010000
c0f04808: 1f788780 <- ReadEDmacDefCorre
c0f04810: df07d0
c0f04900: 1
c0f04904: 40010000
c0f04908: 5e68fc <- ReadEDmacHivshd_V_
c0f04910: 49d0008
c0f04a00: 4
c0f04a08: 6000080 <- ReadEDmacYuv maybe (affects recording)
c0f04a0c: 570001
c0f04a10: 70420
c0f04a14: 70420
c0f04a18: 420
c0f04a1c: fffc640
c0f04a20: 420
c0f04a24: fffc640
c0f04b00: 4
c0f04b08: 56c410 <- ?
c0f04b10: 3e707d0
c0f04c00: 4
c0f04c08: 1c83b8e0 <- ?
c0f04c0c: 1000
c0f04c10: 80
c0f04c14: 1000
c0f04d00: 4
c0f04d08: 1c307800 <- ReadEDmacVram maybe (?! no visible effect)
c0f04d10: 4360f00
c0f04d18: 1f100
c0f04e00: 104
c0f04e04: 80010000
c0f04e08: 700000 <- ?
c0f04e10: 700000
c0f04e20: 100000
c0f04e28: 100000
c0f04e30: 100000
c0f04e34: 7
c0f04f10: 1
lvcdevResourceGet is the key to MJPEG. The problem is that it's not called on new cameras, but only on old ones and only in low-res liveview modes. On 5D3, attempt to call it via TryPostEvent results in ERR70.
Also: some strings in 5D2 might suggest that LVCDEV is used for H.264 recording:
ff966aa4: 'mvrRecForceStop : LVCDEV_H264EncodeResume'
ff966780: 'mvrTerminateEncoder : LVCDEV_H264EncodeStart'
ff9667b8: 'mvrTerminateEncoder : LVCDEV_H264EncodeStart timeout'
ff967870: 'mvrEncode : LVCDEV_H264EncodeStart'
ff9682a0: 'mvrEncodeDone : LVCDEV_H264EncodeStart'
ff9682f4: 'mvrEncodeDone : LVCDEV_H264EncodeSuspend'
ff9689a0: 'mvrRecSuspend : LVCDEV_H264EncodeSuspend'
ff968e00: 'mvrRecResume : LVCDEV_H264EncodeResume'
ff969384: 'mvrSMEncodeDone : LVCDEV_H264EncodeSuspend'
but it's not true, LVCDEV is idle during record.
FA_LvJpegCheck 429392408 << returns this.
called like:
int *foof;
*foof = 24;
FA_LvJpegCheck(&foof);
Also found virtual keyboard but can't get it to come up.
319: 22447.067 [GUI] ERROR ***** GetMenuTypeFromVKType illegal type(0)
320: 22447.176 [GUI] ERROR ***** INPUT_BUF_SIZE = 0
But this OT
Uhm, 1% can you please check
*(0x05724+0x34)
and
*(0x05724+0x38)
The first one should be a pointer and the second one a length of the data contained in the memory pointed by the first...
uhm and +0x4C should be some kind of frame number
LOL
I just realized it's the same address we investigated for the H264 encoder stuff. That memory location is definitely important
They are null even when recording
NSTUB(0xFF111928, str:lvcdevResourceGet_LVC_OUTPUT_DEVICE_T) looks like its supposed to output jpeg or .422 depending on which paths are picked.
According to alex it causes Err70 when called :(
But I've only tried on 5D3.
It doesn't take any parameters? Maybe switch all the a drives to B and then try? Or turn off asserts.
I get this and camera turns off when I call it:
ASSERT: this
at Dev\LiveViewDevState.c:633, task run_test
lv:1 mode:20
Magic Lantern version : v2.3.TRAGIC.2012Sep19.600D102
Mercurial changeset : 26f1e5f44e73+ (unified) tip
Built on 2012-09-19 17:37:17 by user@D610.
Free Memory : 333K + 1434K
Quote from: 1% on September 19, 2012, 07:37:05 PM
It doesn't take any parameters? Maybe switch all the a drives to B and then try? Or turn off asserts.
It takes a tons of parameters actually, most of them are stack based. Some may be set by the other call Alex mentioned
ROM:FF10DF5C var_D8 = -0xD8
ROM:FF10DF5C var_C4 = -0xC4
ROM:FF10DF5C var_C0 = -0xC0
ROM:FF10DF5C var_BC = -0xBC
ROM:FF10DF5C var_B8 = -0xB8
ROM:FF10DF5C var_B4 = -0xB4
ROM:FF10DF5C var_B0 = -0xB0
ROM:FF10DF5C var_AC = -0xAC
ROM:FF10DF5C var_A8 = -0xA8
ROM:FF10DF5C var_A4 = -0xA4
ROM:FF10DF5C var_A0 = -0xA0
ROM:FF10DF5C var_9C = -0x9C
ROM:FF10DF5C var_98 = -0x98
ROM:FF10DF5C var_94 = -0x94
ROM:FF10DF5C var_90 = -0x90
ROM:FF10DF5C var_8C = -0x8C
ROM:FF10DF5C var_8A = -0x8A
ROM:FF10DF5C var_88 = -0x88
ROM:FF10DF5C var_84 = -0x84
ROM:FF10DF5C var_80 = -0x80
ROM:FF10DF5C var_7C = -0x7C
ROM:FF10DF5C var_78 = -0x78
ROM:FF10DF5C var_74 = -0x74
ROM:FF10DF5C var_70 = -0x70
ROM:FF10DF5C var_6C = -0x6C
ROM:FF10DF5C var_68 = -0x68
ROM:FF10DF5C var_64 = -0x64
ROM:FF10DF5C var_60 = -0x60
ROM:FF10DF5C var_5C = -0x5C
ROM:FF10DF5C var_58 = -0x58
ROM:FF10DF5C var_54 = -0x54
ROM:FF10DF5C var_50 = -0x50
ROM:FF10DF5C var_4C = -0x4C
ROM:FF10DF5C var_48 = -0x48
ROM:FF10DF5C var_44 = -0x44
ROM:FF10DF5C var_40 = -0x40
ROM:FF10DF5C var_3C = -0x3C
ROM:FF10DF5C var_38 = -0x38
ROM:FF10DF5C var_34 = -0x34
ROM:FF10DF5C var_30 = -0x30
ROM:FF10DF5C var_2C = -0x2C
ROM:FF10DF5C var_28 = -0x28
ROM:FF10DF5C var_24 = -0x24
ROM:FF10DF5C var_20 = -0x20
ROM:FF10DF5C var_1C = -0x1C
With assert didsabled, lv freezes + turns green with weirdness in it.
Quote from: 1% on September 19, 2012, 07:37:05 PM
ASSERT: this
at Dev\LiveViewDevState.c:633, task run_test
lv:1 mode:20
That's sounds like a null-pointer exception since R0 was null
Quote from: 1% on September 19, 2012, 07:46:04 PM
With assert didsabled, lv freezes + turns green with weirdness in it.
Of course, you're missing something like 30 parameters :P
So how to try it properly? Also does it delete the jpegs/4.22 afterwards? Some usb functions in there too.. .how does LV data get over USB... as jpeg? Would explain the low res.
It looks like that function is actually used to send LV data over PTP to the EOS app...that makes sense
Probably have to patch out:
>JPEG Size Over(%#lx-%#lx)'
and a:\ is the USB?
Also are the LV jpeg addresses still deadbeaf when PTP is hooked up and EOS utility streaming LV?
A and B are the card drives in dual slot cameras. The code reads the active one (it's a check on R0 to decide wether it should use A vs B and JPG vs YUV)
JPEG size over => means that current JPEG was too big, reallocate a bigger chunk of RAM and try again.
This thing might be used to send data to EOS utility, but using that in LiveView doesn't seem to help, the buffer and size are still zero (60D).
Solved the mistery on 60D. Magic word is WriteEDmacPackMem.
So that starts up jpeg?
That's where you find the jpeg buffer. It's only updated in standby (low-resolution modes), including 50/60p.
Next:
- how to get a FullHD JPEG?
- how to make it work on 5D3, where there's no sign of JPEG in the RAM dump?
This is interesting.
There wasn't any jpeg in ram but I didn't check when recording. I can only dump 8MB at a time of ram when recording before buffer gets filled and this is with the lens cap on.
LVCDEV doesn't seem to be active on 600D, so I guess it's disabled (like on 5D3). The 60D was lucky.
Well there is
FF111C58: STRING: '->lvcdevStartDev'
on 600D. So still has to be started another way.
Also: NSTUB(0xFF11189C, str:Dev\LiveViewDevState.c_lvcdevStartDev)
called_by:str:ptpCacheDataStore_ptpCacheCreateMemo
also have: NSTUB(0xFF111630, str:Dev\LiveViewDevState.c_lvcdevInit)
Maybe it lets you chose:
FF111874: '->lvcdevInit' FF111648
FF111888: 'lvcdevStartH264(%d)' FF1116F4
FF111C58: '->lvcdevStartDev' FF1118B8
FF111C78: '->lvcdevResourceGet(%d,%d,%d)'
Initialize then either start h264 or startdev and then do the resourceget.
Tried init then start:
129: 4865.209 [GUI] MainEventHandler PROP_LV_OUTPUT_DEVICE(1)
130: 4874.921 [LV] [EVF] Flicker Detect!!!
131: 4897.217 [LV] [EVF] Flicker Detect!!!
132: 4942.648 [LV] [EVF] Flicker Detect!!!
133: 4988.108 [LV] [EVF] Flicker Detect!!!
134: 5021.262 [LVCDEV] DF 43Hz: 3 50Hz: 3 60Hz: 15 74Hz: 41
135: 5033.565 [LV] [EVF] Flicker Detect!!!
136: 5078.963 [LV] [EVF] Flicker Detect!!!
137: 5110.098 [LVCDEV] DF 43Hz: 3 50Hz: 0 60Hz: 89 74Hz: 4
138: 5124.420 [LV] [EVF] Flicker Detect!!!
139: 5169.848 [LV] [EVF] Flicker Detect!!!
140: 5202.919 [LVCDEV] DF 43Hz: 9 50Hz: 1 60Hz: 18 74Hz: 44
141: 5215.295 [LV] [EVF] Flicker Detect!!!
142: 5260.745 [LV] [EVF] Flicker Detect!!!
143: 5292.132 [LVCDEV] DF 43Hz: 19 50Hz: 3 60Hz: 0 74Hz: 10
144: 5306.182 [LV] [EVF] Flicker Detect!!!
145: 5351.621 [LV] [EVF] Flicker Detect!!!
146: 5384.780 [LVCDEV] DF 43Hz: 34 50Hz: 7 60Hz: 9 74Hz: 6
147: 5384.941 [LVCDEV] Flicker Detect Complete:0
148: 5422.840 [LV] [PATH] GetPathDriveInfo[0]
149: 5669.540 [DISP] Enable Pb 1 (2149)
150: 5805.148 [DISP] TurnOnDisplay finish Type=0
151: 12624.688 [STARTUP] ERROR ASSERT : Dev\LiveViewDevState.c, Task = run_test
152: 12624.793 [STARTUP] ERROR ASSERT : Line 443
153: 12624.845 [STARTUP] ERROR ASSERT : this
154: 12625.009 [STARTUP] startupErrorRequestChangeCBR (0x1d)
155: 12625.077 [STARTUP] startupErrorRequestChangeCBR : ErrorSend (101, ABORT)
156: 12625.385 [STARTUP] ASSERT : Time 2012/9/19 18:42:9
On newer cameras maybe its only started for "flicker detect".
Write edmacpackmem doesn't exist either....
This does but not sure if its useful.
FF3B040C: '[PATH] WriteEDmacFlickerCompleteCBR' FF3B0210
FF3B0434: '[PATH] Flicker_SetPath' FF3B0240
FF3B0450: '[PATH] ResLock CreateLock Hist NG' FF3B0268
FF3B0474: '[PATH] ResLock Lock Hist NG' FF3B0290
FF3B0494: '[PATH] Flicker_StartPath[%lx]' FF3B0304
FF3B04BC: '[PATH] Flicker_StopPath' FF3B0364
FF3B04D4: '[PATH] FLICKER[W](%#lx->%#lx)'
I tried recording a movie along with PTP and it worked... address is still deadbeaf but got some sort of LVCDEV error before flicker detection.
I get this from StartLVTestImage
172: 7211.112 [JOB] ERROR GetImageBuffer failed
173: 7211.223 [LV] ##LV_CaptureTestImage 00000007
174: 7211.510 [LV] ##ChangeProperty PROP_LV_DISPSIZE = 1 (1)
175: 7212.062 ERROR [GMT] GmtEvProc_lv_old_start - State:6
176: 7337.684 [CAPE] ERROR :VRAM(0x445c380)WB(0x40c1260)
177: 7337.783 [CAPE] ERROR :JUKAI WR(0xf528580)RD(0x0)
178: 7337.851 [CAPE] ERROR :JPEG WR(0x0)RD(0xc234700)
179: 7337.918 [CAPE] ERROR :FEN YWR(0x0)WR(0xf6584d0)RD(0x572dc0)
180: 7337.963 [CAP]:ISR >>>>>>>>> HEAD ERROR >>> FIFO ERROR
181: 7338.013 [LV] ERROR [EVF] NotifyHeadErrorCBR
182: 7338.110 [LV] ERROR [PATH] VRAM[W](0xc267a20) YUV[W](0x40d4b80)
183: 7338.184 [LV] ERROR [PATH] FENC[W](0xf575c00) QUARK[W](0x0)
184: 7338.252 [LV] ERROR [PATH] FLIC[W](0x6000978) TA10[R](0x572dc0)
185: 7338.308 [LV] ERROR [PATH] JPEG[R](0x729a60) JPEG[W](0x0)
186: 7353.176 [LV] ERROR [PATH] Path Incomplete[100]
187: 7353.364 [LV] ERROR [PATH] (Rec_HD)CRAW[W](0x44332200->0x46e9460)
188: 7353.933 [LV] ERROR [PATH] (Rec_HD)CRAW[W](0x44332200->0x46e9460)
189: 7387.811 [MR] mvrFixQScale FIX_QSCALE(0:VBR, 1:FIX) = 0
190: 7388.091 [MR] mvrSetDeblockingFilter (alpha = -6, beta = -6)
191: 7388.181 [MR] mvrSetQscaleYC (Y:-12, C:0)
192: 7390.411 [MR] mvrChangeAckCBR : Video - Mode=0, Type=0, Rate=24, GOP=3
193: 7713.703 [CAPE] ERROR :VRAM(0x4476fa0)WB(0x40dc620)
194: 7713.816 [CAPE] ERROR :JUKAI WR(0xf52a380)RD(0x0)
195: 7713.877 [CAPE] ERROR :JPEG WR(0x0)RD(0xc234700)
196: 7713.942 [CAPE] ERROR :FEN YWR(0x0)WR(0xf658580)RD(0x572dc0)
197: 7713.985 [CAP]:ISR >>>>>>>>> HEAD ERROR >>> FIFO ERROR
198: 7714.036 [LV] ERROR [EVF] NotifyHeadErrorCBR
199: 7714.125 [LV] ERROR [PATH] VRAM[W](0xf156ce0) YUV[W](0x40f0cc0)
200: 7714.186 [LV] ERROR [PATH] FENC[W](0xf575c00) QUARK[W](0x0)
201: 7714.256 [LV] ERROR [PATH] FLIC[W](0x6000978) TA10[R](0x572dc0)
202: 7714.317 [LV] ERROR [PATH] JPEG[R](0x729a60) JPEG[W](0x0)
203: 7728.538 [LV] ERROR [PATH] Path Incomplete[100]
204: 7728.722 [LV] ERROR [PATH] (Rec_HD)CRAW[W](0x44332200->0x46e9460)
LV old didn't start for some reason and it gave all of these errors.
Tried in photo mode... after that LV is blank. Still visible on external display tho.
In 0xb40318 FA_GetJpegSizeForLV has flags 0xb402f0 --> 0x18 0xb40308 --> 0x2c
0xb4035c FA_ GetJpegBufforLV 0xb40334 --> 0x18 0xb4034c --> 0x2c
I don't know what this means? I'm working with firmware 101 still haven't updated to 102.
Dumped 0xb3f0e0 to 0xb444b8 found some new function names.
Edit: it looks like 0xb4035c -->FA_GetJpegBufForLV is some how connected to 0xb4250c -->mvrSetD_HD, I don't understand the structure links in this area.
I'm 101 as well. 102 was almost 0 changes.
QuoteOf course, you're missing something like 30 parameters :P
Those, I think:
(http://a1ex.magiclantern.fm/bleeding-edge/ttj/ttj-call.png)
lock = TwoInTwoOutJpegPath_CreateResLockEntry(ttj_struct)
TwoInTwoOutJpegPath_work_maybe(lock, ttj_struct, &output_size, job_id_maybe)
TwoInTwoOutJpegPath_DeleteResLockEntry(lock)
chunk = GetFirstChunkFromSuite_maybe(ttj_struct.off_0x88)
jpeg_address = GetMemoryAddressOfMemoryChunk(chunk)
Some fields from that big structure:
0x00: always points to 0xa0000, passed to CreateResLockEntry
0x04: always 0x1f, passed to CreateResLockEntry
0x08: engio list, enables c0f13000 and configures a few others
0x0c: 0
0x10: engio list, disables c0f13000
0x14: empty engio list?!
0x18: engio list, starts at c0f03218
0x1c: 0
0x20: 0
0x24: 0
0x28: 0
0x2c: 0
0x30: 0
0x34: 0
0x38: ffff
0x3a: image width (16 bit)
0x3c: image height (16 bit)
0x3e: some sort of counter, increases when changing video modes
0x40: 0
0x44: resource lock gets saved there
0x48: a
0x4c: 5
0x50: -1
0x54: 3
0x58: input image buffer address
0x5c: 0
0x80: assigned with 0x20000001
0x88: memory suite where the jpeg data will be written (it's pre-allocated)
fields pointing to ROM addresses seem to be engio structures, they change with video modes
That's a lot of parameters....
But lvcdev seems there, + functions to start it. Just never used in normal mode so no examples on how to get it going.
What is jukai (its some sort of food topping) and quark? Both of those have no write address in the log.
I believe the code was written by Japanese programmers, "Jukai" is a place in japan (sea of trees), where many people go there and commit suicide. Jukai is a place that's often associated with death.
That means it's probably some sort of cleanup routine. Thanks for the info.
(or maybe the code is so fucked up the programmer hated it :P)
I guess they did this on purpose to make reverse engineering more difficult...
one off-topic thing, nanomad there is a grammar mistake in your headline "All your websites are belong to us", it should be "All your websites belong to us" or "All your websites are ours"
http://en.wikipedia.org/wiki/All_your_base_are_belong_to_us ;)
Quote from: a1ex on September 20, 2012, 07:30:45 PM
http://en.wikipedia.org/wiki/All_your_base_are_belong_to_us ;)
that's eye-opening... but it still hurts me when I see grammar mistake :-\
%1, info on WriteEDmacPackMem can be found here http://magiclantern.wikia.com/wiki/Register_Map
Quote from: Marvin on September 20, 2012, 07:29:24 PM
I guess they did this on purpose to make reverse engineering more difficult...
I've actually worked on code where half the functions were documented in Chinese. Never underestimate the laziness of programmers ...
As far as I know most of the "core" development is still done by Canon JP so that actually makes sense
Quote from: nanomad on September 20, 2012, 06:51:23 PM
That means it's probably some sort of cleanup routine. Thanks for the info.
(or maybe the code is so fucked up the programmer hated it :P)
The life is fucked... be a programmer is like living in a bed of roses with many thorns ... lololol
Quote from: 1% on September 19, 2012, 06:39:23 PM
FA_LvJpegCheck 429392408 << returns this.
called like:
int *foof;
*foof = 24;
FA_LvJpegCheck(&foof);
Also found virtual keyboard but can't get it to come up.
319: 22447.067 [GUI] ERROR ***** GetMenuTypeFromVKType illegal type(0)
320: 22447.176 [GUI] ERROR ***** INPUT_BUF_SIZE = 0
But this OT
----------------------------
NSTUB(0xFF8B9B74, StartVirtualKeyboard) // might be good (dumps=1, score=50)
NSTUB(0xFF8B9F24, DlgVirtualKeyboard) // might be good (dumps=1, score=0.97)
NSTUB(0xFF8BC060, StopVirtualKeyboard) // Good. Found matches: ff8bc060/16, ff8bc050/0.18
I tried startvirtualkeyboard but I didn't try the dialog... this would make renaming things, etc much easier, no?
Hehe, there was a reason I didn't want to code for a living....
You keep forgetting about function parameters :P
Try calling StartVirtualKeyboard(0x10) and make sure you have a hidden canon menu in the background
http://imgur.com/KYVQg
Not sure how to set the dmac register.
EngDrvOut(0xC0F27000, 4);
So it worked? Great!
Now we need to figure out where the resulting string is stored
From the 1100D
M:FF10DC10 FA_GetJpegBufForLV ; DATA XREF: ROM:FF535FB0o
ROM:FF10DC10 LDR R0, =0x50AC
ROM:FF10DC14 LDR R0, [R0,#0x38]
ROM:FF10DC18 BX LR
ROM:FF10DC18
ROM:FF10DC18 ; End of function FA_GetJpegBufForLV
ROM:FF10DC1C FA_GetJpegSizeForLV ; DATA XREF: ROM:FF535FA8o
ROM:FF10DC1C LDR R0, =0x50AC
ROM:FF10DC20 LDR R0, [R0,#0x34]
ROM:FF10DC24 BX LR
ROM:FF10DC24
ROM:FF10DC24 ; End of function FA_GetJpegSizeForLV
They are never called like on the 600D :(
Didn't work, was asking if I did that right. Keyboard worked though.
I was talking about the keyboard :P
Did you manage to read the entered string?
Didn't move since I put a canon menu in the background via piggyback function. But I assume where the string goes can be found via looking at the function in firmware. I'd really like to see what how a1ex did pacmem edmac register and see what it does on 600D. Theoretically he shouldn't have LVCDEV running either and when I called the fa test function jpeg has a read buffer or address but not a wire. Better than trying to start it up with all of those parameters.
I think I'm missing a lot of parameters because I'm going off the HTML and not doing it in IDA. Maybe I need to start/learn that and arm console so I can look at more than just what it gives me. I don't see flags or how many parameters it takes, etc.
For me, FA_GetJpegBufferforLV just a pointer.
1%, I don't use IDA, I use http://pel.hu/armu/ good free program. Pel is also a good programmer, photographer and friend.
not 100% under wine but I like it much better than IDA.
Looks nice, I'm trying it :)
I found this in the firwmare 5DC v1.1.1
ff983150 EnoJPEG4:jpgShare.c::CREATED BY M.ENOKIDA, CANON INC.
ff983b6c EnoJPEG4:jpgRCore.c::CREATED BY M.ENOKIDA, CANON INC.
ff986fe4 EnoJPEG4:jpgRScal.c::CREATED BY M.ENOKIDA, CANON INC.
ff9882e0 EnoJPEG4:jpgRVLC.c::CREATED BY M.ENOKIDA, CANON INC.
ff98b704 EnoJPEG4:jpgRClr.c::CREATED BY M.ENOKIDA, CANON INC.
ffab719e encdec_jpeg rev2.12 2004/11/11 Yukio Chiba & Satoshi Naito
and this on the 40D firmware v1.1.1
ffc170e4 EnoJPEG4:jpgShare.c::CREATED BY M.ENOKIDA, CANON INC.
ffc17b14 EnoJPEG4:jpgRCore.c::CREATED BY M.ENOKIDA, CANON INC.
ffc1b210 EnoJPEG4:jpgRScal.c::CREATED BY M.ENOKIDA, CANON INC.
ffc1c4fc EnoJPEG4:jpgRVLC.c::CREATED BY M.ENOKIDA, CANON INC.
ffc29310 EnoJPEG4:jpgRClr.c::CREATED BY M.ENOKIDA, CANON INC.
ffcfdcb6 jp56_jpeg rev3.31 2007/02/19 Yukio Chiba & Satoshi Naito
There is an enojpeg4.dll in canon zoom browser. Wonder whats in it.
Quote from: Chucho on September 22, 2012, 11:54:13 PM
1%, I don't use IDA, I use http://pel.hu/armu/ good free program. Pel is also a good programmer, photographer and friend.
I also already know that emulator but when I tested had some difficulty. In brief test it again. If I need to, I know who I can ask for help :) ... my friend :)
Back OT:
What about:
FF56E9CC: ff111534 ; 0xff111534: pointer to 0xe51f1140
FF56E9D0: ff72db27 ; *'lv_save_jpeg'
OK on 5D2, does nothing on 5D3.
I just called it and did nothing but also called lv_start_old and didn't get an error this time.
Bunch of messages from GMT about mode 6.. but no more error with the paths in it.
[GMT] gmtVDTimming (state:6)
[GMT] gmtProperty ID=0x80050005(0x100)
[GMT] Event 19 Result State 6->6 ID 0x80050005(256)
On 5dII it actually saves a jpeg?
Heh, every time I call it from run_test the card flashes.
Also have : FA_PCLVStart
which calls
NSTUB(0xFF0393A8, PD_LvStart)
That had jpeg on 550D, I'll try calling it too.
rmtFAPCLVStart
SyncSendPipeEvent [0][0][16]
Dispatch : Cur = 0, Event = 16, Param = 0x0
SetOutPutDevice:2,1,2
Change OutPutDevice to PCTFT = 3
pLvCtrlCBR OutPutDevice=(0x3)
GUI_OTHEREVENT:24
WriteDMACInterrupt(2)(0x2)(0)
[ENGIO](Addr:0xc0f04204, Data:0x 0) EngDrvOut
[ENGIO](Addr:0xc0f04200, Data:0x 4) EngDrvOut
[PATH] WriteEDmacYuvCompleteCBR
IDLEHandler OTHER_REMOTE_LV_CTRL new, old(0x3)(0x1)
GUI_SetLvOutputDeviceState (3)
PropCBR camctrl:0x80050011,0x3
ptpPropChangeEvCBR[80050011][4][3]
SendPipeEvent [0][0][9]
changeCBR PropID(0x80050011)Parameter(3)Size(4)
[ENGIO](Addr:0xc0f07134, Data:0x 4)[0]
[EVF] evfSetParamInterrupt
[LVDS] CheckFrame LoopNum1 0
[LVDS] CheckFrame LoopNum2 6 TempFrameCheck 0x3F
[GCTR] LVGAIN_CTRL_GetHShadingData : [49][49][0]
WriteDMACInterrupt(0)(0x2)(0)
[ENGIO](Addr405796b4][0][0]a:0x 0) EngDrvOut
[ENGIO](Addr:0xc0f04000, Data:0x 4) EngDrvOut
[PATH] WriteEDmacWbIntegCompleteCBR
[IRCTR] GetVShadingData(Iso=49)
[IRCTR] GetIRShadingData(po0=80[125](80) Av=2a)
[DCTR] LVDEFECT_CTRL_GetDefmData(H=0)(v=0)
[IRCTR] GetIRShadingData(po0=80[125](80) Av=2a)
WriteDMAC0x4f634c80 - 0x4f634c80] O](Addr:0xc0f04304, Data:0x 0) EngDrvOut
[ENGIO](Addr:0xc0f04300, Data:0x 4) EngDrvOut
[PATH] WriteEDmacVramCompleteCBR
ReadDMACInterrupt(9)(0x2)(0)
[ENGIO](Addr:0xc0f04904, Data:0x 0) EngDrvOut
[ENGIO](Addr:0xc0f04900, Data:0x 4) EngDrvOut
[PATH] ReadEDmacHivshd_V_CompleteCBR
[ENGIO](Addr:0xc0f07148, Data:0x 4)[0]
[EVF] evfReadOutDoneInterrupt
[LVDS] CheckFrame LoopNum1 0
[LVDS] CheckFrame LoopNum2 6 TempFrameCheck 0x3F
[BUFF] RELEASEWRITING[VramArray] (State[3] Addr[0x40d07800][0])
[BUFF] RELEASEWRITING[YuvArray] (State[3] Addr[0x44000080][0])
[BUFF] WRITING[VramArray] (State[1] Addr[0x4f11d800][2])
[BUFF] WRITING[YuvArray] (State[1] Addr[0x44000080][0])
[VRAM] FrameParam[0x90d0e4][0x4f11d800][0x44000080][0x0]
[PATH] Af_StopPath
[ENGIO](Addr:0xc0f100a0, Data:0x 4) EngDrvOut
[ENGIO](Addr:0xc0f100d0, Data:0x 4) EngDrvOut
[ENGIO](Addr:0xc0f10040, Data:0x80000000) EngDrvOut
[PATH] Af_StopPath Complete
[PATH] ObInteg_StopPath[0x0]
[PATH] Hist_StopPath[151de]
[ENGIO](Addr:0xc0f150c0, Data:0x80000000) EngDrvOut
[ENGIO](Addr:0xc0f15080, Data:0x80000000) EngDrvOut
[ENGIO](Addr:0xc0f16018, Data:0x 11) EngDrvOut
[ENGIO](Addr:0xc0f16010, Data:0x 0) EngDrvOut
[ENGIO](Addr:0xc0f16014, Data:0x 0) EngDrvOut
[ENGIO](Addr:0xc0f16008, Data:0x 0) EngDrvOut
[ENGIO](Addr:0xc0f1600c, Data:0x 0) EngDrvOut
[PATH] Hist_StopPath Complete
[PATH] WbInteg_StopPath
[ENGIO](Addr:0xc0f0b0c4, Data:0x 0) EngDrvOut
[ENGIO](Addr:0xc0f0b0c4, Data:0x 1) EngDrvOut
[PATH] WbInteg_StopPath Complete[f529c00]
[ENGIO](Addr:0xc0f09000, Data:0x80000000)[0]
[ENGIO](Addr:0xc0f0b000, Data:0x 1)[1]
[ENGIO](Addr:0xc0f0b004, Data:0x 0)[2]
[ENGIO](Addr:0xc0f11400, Data:0x 1)[0]
[ENGIO](Addr:0xc0f11404, Data:0x 0)[1]
[ENGIO](Addr:0xc0f1100c, Data:0x 0)[2]
[ENGIO](Addr:0xc0f11340, Data:0x 1)[3]
[ENGIO](Addr:0xc0f11380, Data:0x 1)[4]
[ENGIO](Addr:0xc0f2a000, Data:0x80000000)[0]
[ENGIO](Addr:0xc0f11240, Data:0x 1)[0]
[ENGIO](Addr:0xc0f11244, Data:0x 0)[1]
[ENGIO](Addr:0xc0f2c004, Data:0x80000000)[2]
[ENGIO](Addr:0xc0f2c008, Data:0x 0)[3]
[ENGIO](Addr:0xc0f2c00c, Data:0x 0)[4]
[PATH] Rec_HD_StopVramPath[db0400][0]
[ENGIO](Addr:0xc0f0d000, Data:0x80000000)[0]
[ENGIO](Addr:0xc0f11004, Data:0x 0)[1]
[ENGIO](Addr:0xc0f111c0, Data:0x 1)[2]
[ENGIO](Addr:0xc0f112c0, Data:0x 1)[3]
[ENGIO](Addr:0xc0f11300, Data:0x 1)[4]
[ENGIO](Addr:0xc0f11580, Data:0x 1)[5]
[ENGIO](Addr:0xc0f11584, Data:0x 0)[6]
[ENGIO](Addr:0xc0f11440, Data:0x 1)[7]
[ENGIO](Addr:0xc0f11444, Data:0x 0)[8]
[ENGIO](Addr:0xc0f11044, Data:0x 0)[9]
[ENGIO](Addr:0xc0f1a000, Data:0x 1) EngDrvOut
[ENGIO](Addr:0xc0f1a004, Data:0x 0) EngDrvOut
[PATH] Rec_HD_StopPreproPath[c628000][0]
[ENGIO](Addr:0xc0f08130, Data:0x80000000)[0]
[ENGIO](Addr:0xc0f083b0, Data:0x 0)[1]
[ENGIO](Addr:0xc0f08180, Data:0x80000000)[2]
[ENGIO](Addr:0xc0f08020, Data:0x80000000)[3]
[ENGIO](Addr:0xc0f08000, Data:0x80000000)[4]
[ENGIO](Addr:0xc0f08540, Data:0x80000000)[5]
[ENGIO](Addr:0xc0f080a0, Data:0x80000000)[6]
[ENGIO](Addr:0xc0f08090, Data:0x80000000)[7]
[ENGIO](Addr:0xc0f04934, Data:0x 3) EngDrvOut
ReadDMACInterrupt(9)(0x10)(1)
[ENGIO](Addr:0xc0f04904, Data:0x 0) EngDrvOut
[ENGIO](Addr:0xc0f04934, Data:0x 0) EngDrvOut
[ENGIO](Addr:0xc0f04900, Data:0x 4) EngDrvOut
DummyCBR
[ENGIO](Addr:0xc0f04834, Data:0x 3) EngDrvOut
ReadDMACInterrupt(8)(0x10)(1)
[ENGIO](Addr:0xc0f04804, Data:0x 0) EngDrvOut
[ENGIO](Addr:0xc0f04834, Data:0x 0) EngDrvOut
[ENGIO](Addr:0xc0f04800, Data:0x 4) EngDrvOut
[PATH] ReadEDmacDefCorreAbortCBR
[VRAM]vram_SetSenserDriveParameter(73, 1271, 0 1)
[VRAM]vram_SetSenserDriveParameter(0, 0, 0 0)
SDRV_SetDeviceParameter[326]
Then cmos restarts.
600d firmware 101 FA_GetJpegSizeForLV pointer --> 0x4FE2B FA_GetJpegBufForLV pointer --> 0x42100070
Only works when connected to EOS Utility. How to trick the camera to think it's connected? 0xff14b1d8 maybe?
Awesome! you found it. Still said deadbeef when I tried connecting in eos utility even though I was seeing LV and image on the screen.
I've tried
call("FA_PCLVStart");
call("PtpPropMovie");
call("FA_GetJpegSizeForLV");
call("FA_GetJpegBufForLV");
call("lv_save_jpeg");
but still I get deadbeaf even when connected to PC (with LV going). I see signs of PTP and enabling another display in logs.
Am I reading address wrong? Or problem w/ remapped movie mode?
MEMX(0xe51f01e8);
Connected to EOS Utility I dumped ram and got a stream of jpegs starting @ 0x2100070. The jpegs come one after another all are 0x5c010 size and 1056x704 in dimension.
At 0xa030c0 there were two jpegs, 160x120 in dimension.
Edit: I may have dumped the 0x42100070 region by mistake.
Great! I need to try this on 5D3.
Next step is to figure out how to call the JPEG encoder. I've tried to put the parameters from that screenshot on 60D, got ERR70. The lock/unlock calls seem to work though.
That 4 is a caching bit ;)
There already jpegs, all you have to do is prase them out of ram with the .jpeg extension. 0x42100070 is frame 1 plus the size 0x5c010 = 0x4215c80 which is frame 2 and so on. I don't know how many frames they are stored in ram but when you reach the end just loop back to the frame 1.
Is there any chance of a jpg via your work (whilst not recording), a short mov and a jpg from photo mode of the same static scene for comparison?
Use silent pictures - that's the best quality you can get. Jpegs are 422.
Do the jpegs get bigger when you record a movie while connected to the utility? I was able to do this but not dump ram when recording with remap mode (maybe only need to dump from that address onwards). The image on the PC never stopped updating.
mage
Format : JPEG
Width : 1 056 pixels
Height : 704 pixels
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Compression mode : Lossy
http://www.qfpost.com/file/d?g=L3dKtr1Hw (http://www.qfpost.com/file/d?g=L3dKtr1Hw)
8bit with 4:2:2? about 300K each.
Would only need like 9MB/s. There is room to spare unless my numbers are off.
Also found functions: j_PSI_GetLiveViewData at FF038E64 and LV_IMAGE_FORMAT_JPEG_THM_LV_IMAGE_FORMAT_JPEG_ at FF13F4CC
So far get no jpegs trying to start PTP without being connected.
Quote from: a1ex on September 27, 2012, 03:34:28 PM
Use silent pictures - that's the best quality you can get. Jpegs are 422.
Cheers, but I've been there, other threads ;-) I'm interested in comparisons between the three in other regards.
Obviously it will be somewhere in-between. You can do this comparison to see the absolute maximum quality that we can get.
Quote from: y3llow on September 27, 2012, 03:31:02 PM
Is there any chance of a jpg via your work (whilst not recording), a short mov and a jpg from photo mode of the same static scene for comparison?
My observation:
the quality goes like, photo mode JPEG ≥ MJPEG (LV) > .mov file
photo mode JPEG may have an edge on resolution, but in terms of colour and DR they are pretty much the same.
On my 5D3 they are sharper than the movie file, noise seems more finer.
While recording, the PTP pics don't change size. In crop mode, eos utility refuses to show live view screen. I flipped back and forth and found an "idle" sized jpeg in ram.
Interestingly, I found something I recorded a long time ago and maybe deleted at 0x9f2Ef6. It is 160x120 and 4:2:2. It looks like a thumbnail or frame grab but isn't the first video on my card nor are there other jpegs in that area. Why is it there?
Error70 happens when you try to dump a certain address from ram, I think starting at 0x4A. The important part is dump-able, however.
A log from PTP Session:
http://pastebin.com/N7SKLKuF
interesting bit:
563: 31336.478 [PTP] Set OutPutDevice:1,3
564: 31336.565 [PTP] CreateOutPutDevice:[1][3][1]->[3]
565: 31337.849 [GUI] MainEventHandler PROP_LV_OUTPUT_DEVICE(3)
566: 31381.777 [EM] emLockControl (TYPE_REQUEST = 65, 0x0)
567: 31381.818 [EM] RequestLock [ID = 65, 0x5f -> 0x0]
568: 31381.858 [EM] emLockHandler (0x5f => 0x0)
569: 31384.531 [EM] AcceptLock [ID = 65, 0x5f -> 0x0]
570: 31384.583 [EM] emLockControl (TYPE_ACK SUCCESS = 0x0, 0x0)
571: 31387.788 [PTP] NotifyOutPutDevice[1][3][3]->[80000003]
It's easy to get 24 fps in the 500d. First I over right fps in 720 mode to 24fps, 720 and 1080 have the same buffer size. And then I create a AVI file File * f = FIO_ CreateFile(CARD_Drive "test.AVI); if (f != (void*) -1)
And then I loop the write file FIO_WriteFile(f, (void*) 0x42004070, 0x41349); msleep(25);
When I'm done with me loop I slap a RIFF AVI header and FIO_CloseFile(f);
I'm still getting some bad frames but It seem to be getting less then before. The 600D is a little harder, there is a row of about 12 frames. And I can't find the right msleep to sync them together.
On 500D, LiveView is updated at 20fps in 1080p, so you can't get 24p without reconfiguring the timing registers.
I was getting to many bad frames in 1080 so I changed it to 720 and over wrote the frame rate to 24. I'm getting less bad frames now and the resolution are the same in both modes, in the 600d the resolution in 1080 is different then in 720. I just notice all the grammar and spelling mistakes in my last post sorry.
Any luck getting PTP to make the images without being connected? My attempts to start it failed.
1%, no not yet. I was working on the 600d yesterday connected to my PC. I was looking for the right combination of frames and msleep and them it just stop writing AVI files. I don't know why. My AVI don't play back in any player. I think I'm missing to many tags. I'm still working out the header. I prase the jpegs out of the AVI and check for bad frames.
Why not dump image sequence into a folder?
1%, yes I wanted to do that but I found it hard. The jpegs are aways different sizes. And closing the file doesn't give enought head room to create a new file and staying in sync. Alex mention using memcpy it should work for something like that. Also in 720 60fps the frames alternate in size for example frame 1 would be 0x4404F and frame 2 would be 0x4004F. Maybe just scanning for FF D8 FF E0 and cutting just before might work.
Random thoughts:
- There should a prop that gets fired once a frame is ready for PTP to transmit it, unless it's all done in a loop
- Again, PTP must know the size of the frame
your right, here is a stream from the 600d. Lets start with frame 1 0x42100070 just above this frame there is a line with 2 addresses and other information, the addresses are 0x42100010 and 0x42310110. here's a table with the address of the frame and address just above the frame.
Frame1 0x42100070 0x42100010, 0x42310110
Frame2 0x42130080 0x42100060, 0x42190090
Frame3 0x42160090 0x42100060, 0x421c00a0
Frame4 0x421900a0 0x42100060, 0x421f00b0
Frame5 0x421c00b0 0x42100060,0x422500d0
Frame6 0x421f00c0 0x42100060, 0x422500d0
Frame7 0x422200d0 0x42100060, 0x422B00f0
Frame8 0x422500e0 0x42100060, 0x422B00f0
Frame9 0x422800f0 0x42100060, 0x422e0100
Frame10 0x422B0100 0x42100060, 0x42310110
Frame11 0x422E0110 0x42100060, 0x42371030
Frame12 0x42310120 0x42100060, 0x42370130
Frame13 0x42340130 0x42130070, 0x42370130
Frame14 0x423d4160 0x42130070, 0x42404160
And
0x42100010 0x43fffff0, 0x42100060
Would scanning from header (ffd8ffd0) and footer (ffd9) and then scanning again from that end be too slow? Count it along the way while saving to compute size?
yep, isnt that the dma_malloc structure of pointers to previous/next/top blocks?
thats the reason why all HD_BUFFER pointers end with 0x...80
Quote from: Chucho on October 02, 2012, 08:42:04 AM
your right, here is a stream from the 600d. Lets start with frame 1 0x42100070 just above this frame there is a line with 2 addresses and other information, the addresses are 0x42100010 and 0x42310110. here's a table with the address of the frame and address just above the frame.
Frame1 0x42100070 0x42100010, 0x42310110
Frame2 0x42130080 0x42100060, 0x42190090
Frame3 0x42160090 0x42100060, 0x421c00a0
Frame4 0x421900a0 0x42100060, 0x421f00b0
Frame5 0x421c00b0 0x42100060,0x422500d0
Frame6 0x421f00c0 0x42100060, 0x422500d0
Frame7 0x422200d0 0x42100060, 0x422B00f0
Frame8 0x422500e0 0x42100060, 0x422B00f0
Frame9 0x422800f0 0x42100060, 0x422e0100
Frame10 0x422B0100 0x42100060, 0x42310110
Frame11 0x422E0110 0x42100060, 0x42371030
Frame12 0x42310120 0x42100060, 0x42370130
Frame13 0x42340130 0x42130070, 0x42370130
Frame14 0x423d4160 0x42130070, 0x42404160
And
0x42100010 0x43fffff0, 0x42100060
Yes, that's exactly what it is
Chucho where did you get the address location from? I'm quite sure the "base pointer" is actually saved in a 0xABCD memory region.
I'll drop the memory locations I've marked as interesting:
int base = 0x5B0C
void* interesting = *(base+0x28)
interesting looks like an array of pointers, size unknown
I think the best way is to re-program the DMA to write the jpegs in your own huge buffer (up to 192 MB if I remember well). This is how I plan to do it to get rid of frame skipping.
For those who didn't see my tests:
http://a1ex.magiclantern.fm/bleeding-edge/crop.avi - mjpeg recorded on 5d2 in crop mode (use mplayer or vlc)
http://a1ex.magiclantern.fm/bleeding-edge/noncrop.mov - normal video (H.264) with the same lens and settings
I saw it a couple of months ago but you didn't tell me the crop version was an mjpeg :D
Nice job.
Reprogramming it will also be necessary to get bigger jpegs. 192mb is a pretty big buffer. Those clips are very motivating :)
What exactly needs to be worked on? Except the enabling LV jpeg buffer in some models.
Jpegs aren't full size. Get converted to LV size. I thought while recording actual LV size was bigger. Also doesn't work in crop mode for some reason.
Could PTP Jpeg be enabled via a property? I made a log of a PTP session and it keeps doing this:
mvrChangeAckCBR : Video - Mode=0, Type=0, Rate=24, GOP=3
ptpPropChangeEvCBR[80000039][14][0]
SendPipeEvent [0][0][9]
SendPipeEvent [0][0][49]
changeCBR PropID(0x80000039)Parameter(0)Size(20)
changeCBR PropID(0x8000003c)Parameter(0)Size(4)
changeCBR PropID(0x80000041)Parameter(0)Size(4)
changeCBR PropID(0x80000005)Parameter(107)Size(4)
->lvcdevProperty ID=0x80000039(0x0)
[GMT] gmtProperty ID=0x80000039(0x0)
[GMT] PROP_MOVIE_PARAM Asp:6
[GMT] PROP_MOVIE_PARAM Mode:0, R(4->4), SC(0->0) SZ(0->0)
[GMT] PROP_MOVIE_PARAM DZ(0->0)
[GMT] Event 19 Result State 6->6 ID 0x80000039(0)
[GMT] gmtProperty ID=0x8000003c(0x0)
[GMT] PROP_MOVIE_REC_AF:(0)
[GMT] Event 19 Result State 6->6 ID 0x8000003C(0)
[GMT] gmtProperty ID=0x80000005(0x6b)
[GMT] Event 19 Result State 6->6 ID 0x80000005(107)
copyDataToStorage eventID(0x80000039)Data(9487752)size(20)
PROP_MOVIE_PARAM [9487752]
The rest:
http://pastebin.com/NGLTs3VB
Also:
NSTUB(0xFF0967C8, str:Develop\FrontDevelopState.c_sdsActivate_Enable)
Uses yuv to jpeg path and there is some sort of debug monitor:
FF096DB4: e59f12f8 ldr r1, [pc, #760] ; pointer to sub_FF096604 ⬁
FF096DB8: e28f0fbe add r0, pc, #760 ; *'EnableDebugMon'
Unsure if its the sub or what happens below.
From function 0xff14b1d8 PtpPropMovie R1 = 0x80020009 R0= pointer 5BD4 --> 0x44E002C Off (not connected to EOS Utility), 0x2B6002C On (connected to EOS Utility). How do I test this? Off topic how can I use NSTUB(0xFF010BA4, memMap) and NSTUB(0xFF010C20, objInfo)
5BD4 points to 0x49e007a for me whether connected to PTP or not. The contents of that address is FFFFFFF whether connected or not.
0x80020009 is I think the actual property. Have to look at it in property spy, than maybe can change with the property handler?
These properties show up when connected to eos utility:
That 0x80020009 contains address 0x41000000
[img=http://s3d4.turboimagehost.com/t1/13540055_IMAG0577.jpg] (http://www.turboimagehost.com/p/13540055/IMAG0577.jpg.html) [img=http://s3d4.turboimagehost.com/t1/13540056_IMAG0578.jpg] (http://www.turboimagehost.com/p/13540056/IMAG0578.jpg.html) [img=http://s3d4.turboimagehost.com/t1/13540057_IMAG0579.jpg] (http://www.turboimagehost.com/p/13540057/IMAG0579.jpg.html) [img=http://s3d4.turboimagehost.com/t1/13540059_IMAG0580.jpg] (http://www.turboimagehost.com/p/13540059/IMAG0580.jpg.html)
That property defined as: PROP_ICU_UILOCK 0x80020009
The 2a and 2b properties are 2 and 1 so that looks like some sort of mode... I did not find them in the property.h
Also what is:
PROP_LV_AFFRAME 0x80050007 // called by ptp handler 915a
I see reference to making "AF Frame" in fw in ptp functions.
Maybe I'm trying too hard...
call("WriteEDmacPackMem");
starts PTP and jpegs are created but they don't show up in ram. Am i missing a parameter?
ptpPropChangeEvCBR[80000039][14][0]
SendPipeEvent [0][0][9]
SendPipeEvent [0][0][49]
changeCBR PropID(0x80000039)Parameter(0)Size(20)
changeCBR PropID(0x8000003c)Parameter(0)Size(4)
changeCBR PropID(0x80000041)Parameter(0)Size(4)
changeCBR PropID(0x80000005)Parameter(104)Size(4)
->lvcdevProperty ID=0x80000039(0x0)
[GMT] gmtProperty ID=0x80000039(0x0)
[GMT] PROP_MOVIE_PARAM Asp:6
[GMT] PROP_MOVIE_PARAM Mode:0, R(4->4), SC(0->0) SZ(0->0)
[GMT] PROP_MOVIE_PARAM DZ(0->0)
[GMT] Event 19 Result State 6->6 ID 0x80000039(0)
[GMT] gmtProperty ID=0x8000003c(0x0)
[GMT] PROP_MOVIE_REC_AF:(0)
[GMT] Event 19 Result State 6->6 ID 0x8000003C(0)
[GMT] gmtProperty ID=0x80000005(0x68)
[GMT] Event 19 Result State 6->6 ID 0x80000005(104)
copyDataToStorage eventID(0x80000039)Data(13077236)size(20)
PROP_MOVIE_PARAM [13077236]
copyDataToStorage eventID(0x8000003c)Data(0)size(0)
copyDataToStorage eventID(0x80000041)Data(0)size(0)
copyDataToStorage eventID(0x80000005)Data(104)size(0)
From log are they 0 size?
NSTUB(0xFF14B1D8, PtpDpsRmtReleaseEventFlag)
then:
call("WriteEDmacPackMem");
msleep(1000);
call(PtpDpsRmtReleaseEventFlag);
get 160x120 jpeg from 0x0a067c1e to
0x0a06ca3c
Messing with the event flags produces corrupted jpegs sometimes.
Nothing is consistant even though PTP is rolling.
CreateEventFlag('PtpPropMovie', 0x1);
CreateEventFlag('PtpPropUIlock', 0x1);
I have know idea what all this means and if i did i would be developing! all i know is this would be an awsome feature! mjpeg or just a jpeg sequence would be way better the h.264 as far as quality goes! Whats the latest on this beast of a feature?
Funny thing, The 350d is the only Canon dslr with a MPEG1 and MPEG2 encoder string, besides the 1DC. The 350d doesn't even have LIveview. There goes my theory about how dslr were never meant to record video, apparently Canon was development video recording early on.
Or maybe they just reused some code from video camera division or point and shoots?
What do those function go to now? There is an AVI player for some reason and as far as I know the DSLRs never recorded AVI.
If we can resize those jpegs from 0 then MJPEG just needs to be saved to file. Did you do anything besides call WriteEdmacPackMem on 60D?
Quote from: a1ex on November 02, 2012, 08:29:31 PM
Or maybe they just reused some code from video camera division or point and shoots?
It's all about the JPCORE. The 350D has JP52, the newer cameras have JP60 or 61 I can't remember. The 5d3 has the newer JPCORE6' something, it also has the JP57 which it uses for raw pictures? But why did they go back to JP57 wasn't the newer JPCORE good enough?
I think JP62 for me.
1100D and 600D have JP62
Does 7d produce jpegs without the USB cable?
do you mean LV JPEG encoding without any reason?
if so: yes ( http://youtu.be/jQLHkXL-AWU )
Is the 7D the only one that does it?
Wait, did I miss something? Do the jpeg contain actual LV image data?
yes, its the LV content JPEG compressed.
1056x704
600D does when USB is connected :(
Quote from: g3gg0 on November 03, 2012, 12:56:51 AM
yes, its the LV content JPEG compressed.
1056x704
600D does when USB is connected :(
What about X0D cameras and 5DII?
If it doesn't call that edmac register on don't click me and dump ram. If it is LV does that mean jpeg will be 4:4:4 when in HDMI and switched? Into something that supports 4:4:4 the image wasn't red, only the ML menus. But yuv I think still 4:2:2.
I did some testing:
Jpeg has no overlays. When connected to HDMI YUV size stays at 1056x704 but image is in both screens. 4:4:4 affects HDMI display but not JPEG. Also... silent pics correctly play back on HDMI and LV doesn't die while USB is connected. I wish I could try in crop mode but I don't know if the eos utility is saying "LV doesn't work in crop mode" or if its somethign that can be cache hacked out of the camera. I did not find the strings.
Quote from: g3gg0 on November 03, 2012, 12:56:51 AM
yes, its the LV content JPEG compressed.
1056x704
600D does when USB is connected :(
Nice! how heavy is the Jpeg compression on them?
An uncompressed 1056x704 8bit 4:2:2 image is 1,486,848 bytes (1.5MB) and "Highest Quality" JPEGs are usually a 2.5:1 compression ratio which should be around 600KB per jpeg file. I read somewhere they were around 300KB each which would be a 5:1 (not bad!) ;D
They are 320KB.
oh hm continuous JPEG saving code is for nuts on 7D.
just set 0x60D8 to 0x01 and the canon stock code will already dump all frames.
no need to synchronize and add manual code.
Can you upload a sample jpeg vs a frame taken during video mode (fullHD?), i'd like to compare the quality
What functions actually do it? Maybe possible to do this to other cameras, just not identified.
I posted a jpeg posts back but not against a video frame.
Quote from: g3gg0 on November 03, 2012, 05:30:30 PM
oh hm continuous JPEG saving code is for nuts on 7D.
just set 0x60D8 to 0x01 and the canon stock code will already dump all frames.
no need to synchronize and add manual code.
Interesting...
So this actually is something Canon has got inside its FW?
LV JPEG
http://upload.g3gg0.de/pub_files/5bfb673879c1349b45c50aa7575c46aa/LV000023.JPG
VLC snapshot with 1.0x CBR
http://upload.g3gg0.de/pub_files/d0c870f9aeda37a8e10ca8a239873c16/vlcsnap-2012-11-03-18h03m03s246.png
I think the LV buffer is better, even when upscaled to 1920x1280
http://i.imgur.com/ll2P3.jpg
edit: actually, I don't really know :/
Looks pretty similar... just one is scaled down and one is scaled up. Same YUV source.
Yes, and moire / noise is more visible in the jpg version giving a false "it has more details" impression at first glance
You do have the 4:2:2 color in the jpeg though... and if it can be resized its better and less stress on the CPU. Plus you can monitor in HD while doing jpeg as I've found.
Is MJPEG image data the same as HDMI output image data? (which can recorded to external recorder?)
Canon's output is compressed, so it is MJPEG LV image data, yes?
So implemented MJPEG-video is the way to achieve external recording quality internally. Am I correct?
Somewhat. Its neither LV nor HDMI. Things that affect HDMI don't affect jpeg, I think its a separate function. But it will achieve 4:2:2 at some size internally.
LV is 720x480, YUV is 1680x9something and jpeg is ~1056x704. Overlays don't show up on it, runs along with 1080P hdmi or live view AND while recording a movie. So compressing YUV to YUV sized jpeg will probably make the best quality. Even as separate frames they can be combined as an image sequence to whatever video. I don't know about dropped or mangled frames, however or how smooth it will be.
the flag at address 0x60D8 allows different settings.
0x01 dump JPEG to A:
0x02 dump JPEG to B:
0x03 dump .422 to A:
0x04 dump .422 to B:
0x05 dump JPEG+.422 to A:
0x06 dump JPEG+.422 to B:
but the .422 dumping will be slower than my card of course (30MB/s)
so it will produce some corrupted .422s and some with "old" content only.
still funny to use ;)
Ok so:
LV = 720x480p at ??fps 4:2:2 with no frame compressions
HDMI = 1620x910i at 60fps 4:2:2 with no frame compressions
MJPEG = 1056x704p at ??fps 4:2:2 with JPEG compressions?
I've noticed when checking my "LiveV FPS" I get 60fps.
Is that using the 1056x704 or 720x480 buffer?
If the former, then that means it could get 1056x704 in 4:2:2 at 60fps right?
Quote from: g3gg0 on November 03, 2012, 10:08:16 PM
the flag at address 0x60D8 allows different settings.
0x01 dump JPEG to A:
0x02 dump JPEG to B:
0x03 dump .422 to A:
0x04 dump .422 to B:
0x05 dump JPEG+.422 to A:
0x06 dump JPEG+.422 to B:
but the .422 dumping will be slower than my card of course (30MB/s)
so it will produce some corrupted .422s and some with "old" content only.
still funny to use ;)
Any piece of code for that? I'd love to try right now.
you can set address e.g. via ptpcam
Quote from: g3gg0 on November 03, 2012, 10:58:35 PM
you can set address e.g. via ptpcam
I don't know if i can do this.
Can you give me a hint?
:D
Quote from: 1% on November 03, 2012, 06:34:08 PM
Looks pretty similar... just one is scaled down and one is scaled up. Same YUV source.
Do you see the fine horizontal lines across the LV jpg? especially visible across smoother surfaces? I see these on all LV silentpics (whilst not recording) I've captured.
Also, why aren't silent pictures taken during recording readable? They have twice the size of a standby SP on my 50D.
Quote from: 1% on September 19, 2012, 06:39:23 PM
Also found virtual keyboard but can't get it to come up.
319: 22447.067 [GUI] ERROR ***** GetMenuTypeFromVKType illegal type(0)
320: 22447.176 [GUI] ERROR ***** INPUT_BUF_SIZE = 0
But this OT
I've got to see VirtualKeyboard in 40D.
Gonna try out those commits right now and see what happens. My movie mode silent pics = recording silent pics now because new silent pic taking permanently did some stuff.
Quote from: 1% on September 22, 2012, 06:08:21 AM
http://imgur.com/KYVQg
Not sure how to set the dmac register.
EngDrvOut(0xC0F27000, 4);
I had seen this picture before ...
Quote
Also, why aren't silent pictures taken during recording readable
They're readable, just a different size. Get the gimp extension that opens .422
Get "Failed to wait until LV buffer updates" for both .422 and jpeg.
It does work while tethered... I tried:
int *jpegz = (int *)(0x60D8);
*jpegz=0x2;
msleep(2000);
call("WriteEDmacPackMem");
But still no dice.
High res pics still work...
A suggestion... make the bursts/continuous create a new folder each time. And also thanks for adding this :)
*Killing silent pic wait loop fixed taking silent pics. But what is FPS of them really? Seems like they speed up/slow down. My card didn't seem to have trouble keeping up even with the 3MB files. Still no fix for Jpeg :(
I know its not exactly mjpeg but I shot a bunch of .422s. 368 over about ~3 minutes. That's like 2fps? 422 to Image doesn't want to convert them :(
I'll try some tethered jpeg and see what kind of fps I get. Hmm... it seems pretty decent... also noticed this:
Tethering is now shrinking my YUV buffer to 1056x704.. in crop mode the utility refuses to work. While recording tethered, the jpegs stop coming until recording stops. PC still updates with LV image and the jpegs are in ram if they are dumped (1056 only). So 2 things:
1. Canon blocks jpegs when YUV is bigger
2. Your function is separate from the EOS utility jpeg which gives hope that if patched it will make bigger sizes.
Quote from: 1% on November 04, 2012, 01:32:31 AM
They're readable, just a different size. Get the gimp extension that opens .422
I didn't know this, thanks.
600D: Jpegs are working when connected to any kind of usb.
0x5748 and 0x5770 are 2 flags that have something to do with it.
Same on the 1100D, strange eh?
What about other cameras? The 50D might be similar to the 5DII, i would like to try if i can save jpegs as well.
Find the 3 functions added to 600D stubs and it will work.
The 1100D has an interesting piece of code labelled lv_save_jpeg
ROM:FF10DB78 lv_save_jpeg ; DATA XREF: ROM:FF5368D8o
ROM:FF10DB78 LDR R0, [R0]
ROM:FF10DB7C LDR R1, =0x50AC
ROM:FF10DB80 STR R0, [R1,#0x24]
ROM:FF10DB84 BX LR
What happens when you store 0x24 in the address? My card just got corrupted messing with those 2 flags.
On 5D2, th syntax is: call("lv_save_jpeg", 1).
yep, lv_save_jpeg is the function that enabled the flag i told.
its the same as setting the memory variable via ptp.
Yep. and it's nuts speed-wise. I'll dig into the code that actually does the switching to check why it won't run in non-PTP mode (it blinks once and doesn't save anything)
If you call that packmem edmac, PTP runs. But with no usb it doesn't send the data anywhere. A separate function disables the getjpeg stuff as it stops when recording, etc.
* With globaldraw off and CPU usage down the jpegs save much faster.
Some hope for FPS override too... I see LV fps of up to 70.
Made some movies with both .422 and jpeg. The effect is kinda funny. I think these need to compute FPS at the end so you can guess at a frame rate.
So if mjpeg was possible on the 5d3. would they be 1024x64 what ever or is the 5d3 different. uncompressed or mjpeg codecs like these would b a dream! i know file sizes will be bigger but who cares! i realy wish i could help you guys fig this one out! This is very impressive thus far and im constantly on this site checking for updates ha ha. great work yall!
Isn't the frame rate of the live view whatever it is the frame rate is set to. Or does live view have it's own screen hz frame rate.
Its using the 2 functions to get size and address so its going much slower than LV fps right now.
Quote from: 1% on November 07, 2012, 02:52:26 PM
Its using the 2 functions to get size and address so its going much slower than LV fps right now.
I think i don't understand.
I checked the LV fps on my 50D at the standard Full HD 30p and i can't understand why it shows 16 fps sometimes. Then, other times, i get 32.7 fps so it leaves me a bit confused about what's going on.
CPU usage? When you turn off global draw or things like peaking/zebras it goes up.
Also, canon function drops jpegs at at least 15fps. They end up in DCIM. I'll see if it goes faster with GD off and how fast the 422 is.
I don't have my 600d at the moment but has anybody tried calling the actual code the writes the liveview jpegs. In the 600d the fuction starts at 0xFF111928 and you can see the code that writes the jpegs at 0xFF111B7C
I've tried to call the TTJ thingie on 60D, with that big list of parameters described above, no success.
As long as Canon code is creating the jpegs, I can record MJPEG fairly well (at low resolution, of course).
On 5D3 I've tried to inject some events in the LVCDEV machine. I can trigger the state transitions, but I'm not passing some memory suite correctly (I get ERR70 about that).
Interesting that the function doesn't write the .422s without usb connected either.
whats the word on the mjpeg? is it possible to get just sequences of hd jpegs at 24p on 5d3 seperated by folders? Then we could just stitch it together in post. It might mean no playback in cam but id sure take it if it ment nice fine jpeg noise!