(M)JPEG encoder

[1%]

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.

Code: [Select]

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.

[Chucho]

600d firmware 101 FA_GetJpegSizeForLV pointer --> 0x4FE2B FA_GetJpegBufForLV pointer --> 0x42100070

[Chucho]

Only works when connected to EOS Utility. How to trick the camera to think it's connected? 0xff14b1d8 maybe?

[1%]

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

Code: [Select]

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);

[Chucho]

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.

[a1ex]

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

[Chucho]

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.

[deleted.account]

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?

[a1ex]

Use silent pictures - that's the best quality you can get. Jpegs are 422.

[1%]

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.

Code: [Select]

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

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.

[deleted.account]

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.

[a1ex]

Obviously it will be somewhere in-between. You can do this comparison to see the absolute maximum quality that we can get.

[Marvin]

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.

[1%]

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:

Code: [Select]

    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]


[Chucho]

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.

[a1ex]

On 500D, LiveView is updated at 20fps in 1080p, so you can't get 24p without reconfiguring the timing registers.

[Chucho]

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.

[1%]

Any luck getting PTP to make the images without being connected? My attempts to start it failed.

[Chucho]

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.

[1%]

Why not dump image sequence into a folder?

[Chucho]

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.

[nanomad]

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

[Chucho]

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

[1%]

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?

[g3gg0]

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

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