Canon 40D

[theBilalFakhouri]

Expanding the preview is done in YUV HD path, that would mean in x5 Mode you can get less crop in YUV HD stream . . Changing YUV HD buffer is not required to expand the preview .. but

I could change YUV HD buffer size too, in 700D in Idle mv720 and mv1080 YUV HD buffer is 960x540, when recording H.264 video in mv1080 the buffer changes to 1728x1151, in mv720 it changes to 1280x689, and after that H.264 Encoder compresses it , taking a look what's happening between Idle and H.264, I can identify one EDMAC channel register which control the buffer size, and other registers related to it which make the expanded YUV buffer size usable instead of being black.

I got in mv1080 1728x1151 instead of 960x540 in Idle
           mv720   1728x540   instead of 960x540 in Idle (1728x689 would be possible)

So now 1 RAW Pixel = 1 YUV Pixel

in x5 Mode Buffer size is 1032x687 which matches 1032x687 of RAW data directly, expanded the processed RAW data in YUV HD stream (Expanding the preview) with increasing the YUV buffer size is possible, I got more than 1032 buffer width matches more than 1032 RAW data , but there is a limit at some point.

More Info at LiveView Investigation.

I don't think you need to change ADTG or CMOS, unless you want to increase the RAW data.

[heder]

Hi theBilalFakhouri

Thanks for the input, looks really interessing with the YUV changes in your liveview thread, I'll try that out when I am ready. Currently working on the initial release, then afterward expanded the YUV buffer sizes so I can fit more pixels into that. In raw video x5 mode I get max 1920x804, and getting mjpeg 1920x804 would be nice for a camera that was'nt build with video recording capabilities.   

[theBilalFakhouri]

That would very cool for 40D, Good Luck, Nice work! I am excited to take a look into MJPEG code

[Ant123]

I am excited to take a look into MJPEG code

You can look into my current version

But:

On newer models (DIGIC 5, IIRC also 60D and newer DIGIC 4), this function no longer runs automagically while in LiveView, so this approach is only valid for older models.

[heder]

This is what happens in the main lv jpeg compression function called in liveview

"LVJpegEncodePath":
1. Create a event flag
2. lock used engine resources
3. Setup edmacs, jpeg core registers
4. Start edmac transfers (YUV422 => jpeg core) and start jpeg core
5. Wait for core to complete (wait for event flag)
6. Delete flag
7. unlock used engine resources

Its going to be hard to get that running on other cams, but is not impossible. This actually look 99.99% excat the same as when photo mode does the excat same compression on the 40D ("JpegEncodePath"). It's a single isolated function, called in the LiveView.

[ArchThor]

Hi all,

So, went through all pages here and just wanted to confirm if I maybe a bit too dumb to understand the codes used here or the LiveView "timeout" is not on the list of mods planned.

Currently my 40D times out at around 30 min and closes LiveView (I am using at work as a webcam to present stuff to the team, so EOS Camera Movie Recorder + OBS), but I could only find the LiveView mentions as being part of the video function, if I got it correctly. Do you know if there is any flag I could maybe change to remove the limit to it?

Thanks!

[heder]

Hi all,

So, went through all pages here and just wanted to confirm if I maybe a bit too dumb to understand the codes used here or the LiveView "timeout" is not on the list of mods planned.

Currently my 40D times out at around 30 min and closes LiveView (I am using at work as a webcam to present stuff to the team, so EOS Camera Movie Recorder + OBS), but I could only find the LiveView mentions as being part of the video function, if I got it correctly. Do you know if there is any flag I could maybe change to remove the limit to it?

Thanks!

Hi ArchThor.

I didn't even know there was a 30 minute limitation, so I will look into this when I have the time. I have LUA scripting
module running (but not released yet), and perhaps I can merge with the LUA fix scripting branch, and using
the LUA module avoid/fix this limitation, but no ETA on when this is ready.

[imme]

hi,
any updates 

[heder]

I'm still working on mjpeg streaming.  Ant123's module would not run record smoothly, so I reworking Ant123's module, making it more towards mlv_lite but my reworked module is not working yet.  Also due to house renovation progress is a little slow lately, but I have not forgotten the ML project 


 

[kidkoala83]

Managed to boot your build in qemu, now i can boot both canon firmware and your ML build.



Next I'll try to run it in the camera and dump the RAM.. Also.. How would one go about finding the half shutter button? Id like to try that.
Thanks for your work heder!

[heder]

Managed to boot your build in qemu, now i can boot both canon firmware and your ML build.



Next I'll try to run it in the camera and dump the RAM.. Also.. How would one go about finding the half shutter button? Id like to try that.
Thanks for your work heder!

Hi, your qemu looks really good  (mine is crap)


My lastest build is here my lastest build (source code) is here
https://github.com/jmheder/ml/raw/master/vxworks_1.0.5.zip The half shutter fix is included, but only lightly tested. The source that fixes the half shutter is platform/40D.111/sal-digic4/sal-gui.c (the function is called sal_GUI_E_Control). Basically i'm hijacking the GUI_E_Control function and checking for half shutter.  It's not the best solution, but because the half shutter on Digic3 is not like on the Digic4 platform, hijacking GUI_E_Control was the easy way of getting "the job done".

If you get stuck, just ask, there's no bad questions, just bad answers.

I'm still working on mjpeg, totally stuck, fighting with odd errors, I dont understand.

[heder]

A new incomplete list of stuff todo

* edmac module fails (edmac is working, but module fails)
* beep sound not implemented
* auto exposure value not detected (I gave up on this one)
* ants mjpeg module is not recording correctly (working on this)
* get 40D branch on heptapod
* compile and test 40D with gcc 6.x compiler.
* Lua module is loading and working, but is it useable ??
* 1st memory job stub function not found.
* lots of PROP_ (properties) not aligned.
* zebras in liveview missing
* global draw (zebras,histogram) not shown in photo mode (= crash)
* Better SW1/SW2 activation
* continue to update https://magiclantern.fandom.com/wiki/Register_Map/40D
* Optimal Mirror lockup not implemented (as minimum the curtain is activated), disable the curtain activation

* 10/12 bits raw video,
  => Theoretical: (10 bits, 23.976 fps, 1:2.39 = 1056x432) &  (12 bits, 23.976 fps, 1:2.39 = 960x400)
  => Require merge with 10/12 bit branch

* LV state mashine
   => not re-engineered
   => VSync er performed via EngDrvOut hijack (ok for now)

* FIO_SeekSkipFile does not work at all .. why ?
   => SEEK_CUR,SEEK_END fails.
   => only SEEK_SET seems to work ..
   => could be cache ?
   => could be interface ? / parameter swapped ?

* selftest module fails
  => only a few tests runs as they should

* bench module fails
   => issue with memory allocation,
   => CF card benchmark may not be performed with buffers > 2 MB or the system halts
 
* memory system allocation
   => still fails on large buffers, bench module fails, selftest modules fails.
   => mlv_lite does not fail. (allocates above 20 MB)

[heder]

Finally a little progress on the port.

I finally found the missing bugs in the FIO_ system which have been annoying, I found two issues.

The interface on FIO_SeekSkipFile is wrong. The interface in magic lantern (DryOs) is specified as: int64_t FIO_SeekSkipFile(FILE *, int64_t offset, int whence); but VxWorks interface is actually: int32_t FIO_SeekSkipFile(FILE *, int32_t offset, int whence); No wonder I could'nt seek inside a file at all! (all seeks was SEEK_SET due to wrong parameter sizes)

The other bug was the O_SYNC flag screws up operations. FIO_CreateFileOrAppend would not perform correctly when seeking inside a file because if was opended with O_SYNC. It seems like O_SYNC is'nt supported (?). I tryed with both cache and uncache memory, both fails with O_SYNC. Removing O_SYNC from opening file solved the issue.

And with console.c writing console.log correctly (now) I can assume hunting the last fio_malloc() bugs ..

[Ant123]

FIO_SeekSkipFile: should be testable in QEMU, with a large SD image and the test code from selftest.mo. That test will create a large file (2GB) and seek within that file.

There are two versions in Canon firmware: one that accepts 32 bits for the position and another one that accepts 64 bits. They are not interchangeable at binary level.