Messages

Have you tried to logging MMIO traffic through JPCore?

I'm logging all engio functions, including a special one on the 40D assigned only to JPEG, but since you'r asking ..  I suddenly remeber I have seen multiple jpeg registers set directly without call to engio function somewhere, now I must hunt for these value!.
 

[horizontal]

General note: from own preview experiments on 700D/5D3, LiveView seems to have multiple layers, if one of the layers didn't match horizontal resolution of e.g. YUV path, some artifact would show (similar to your image). But no idea if it the same thing in your case.

Try to compare registers among none crop mode vs x5 mode, tweak registers you found and see if one of the registers causes these kind of artifacts. We usually do this by adtg_gui module on DIGIC 4/5.



If x5 mode works for JPEG recording and you prefer none-crop mode, You can patch 1:1 (x5) mode back to 3x3 (none crop) mode without touching preview registers, see this. This can be done using CMOS and ADTG registers and it's very simple. We also can do this by adtg_gui module, and it's very simple to do it. Unfortunately no idea how to do it on 40D.

Thanks for input.

The YUV Path runs correctly. I don't have any artefacts, and the registers are quite similar to the one you descripted. The image from 6 March is a image from the updated YUV path. (greyscale image, converted from YUV).  It's the JPEG "path" compressions that run incorrectly, but the JPEG engine is largely undocumented. The YUV is transferred in macro 8x8 blocks into the JPEG engine in a specific pattern, properly due to JPEG engine ram or similar (and another EDMAC is configured to readout on the fly, this works fine). I had compute re-compute the EDMAC value in order to get image transferred. By looking at the different video/photo modes I was capable of re-computing the new EDMAC values. This works for some image width (1024,1088,1280), but I get those artefacts.  I did compare x1 versus x5/x10 inorder to get a feeling for that needs to be updated, EDMAC and JPEG registers.

Basically I'm hijacking the 40D JPEG Path "main" call and changing the image size, and JPEG engine get correctly configured, but the EDMAC value for transferring into the JPEG engine is hardcoded and those is changed on the fly. Also some JPEG related registers needs to be corrected for the entire path to run.

My current assumption is 

1. Either I'm missing at update some JPEG related registers
2. or EDMAC is configured incorrectly.

I have been working on getting the mjpeg video recording running at 1336x872 (non crop mode) or similar but it partly fails. The original size 1024x780 is'nt interessing due to the small size. I actually have the YUV conversion path running (sensor->YUV conversion), see post from 6 of March 2022, but the YUV->JPEG path partly fails. I do get a correctly sized image with good pixels, but I also have a green pattern all over the place. I have failed to fix this so far. No one have documented to JPEG engine and registers so it's a black box.

Here is my pattern problem:



I'll give it another month, and If I fails, I'll try to x5 zoom mode. x5 zoom mode is harder to work on, because I need to change much more registers, but I properly have a slightly higher properbility of success with the YUV->JPEG path as the 40D can save JPEG photo images in 1936x1288 format (small size), and I can utilize this to find the correct registers for a 1936x1288. Max format in crop more (x5,x10) is 1944x806 (full HD 1:2.39)

[10800 frames.]

Hi Peter

Your goal is to get maximum of 9000 frames in 3 minuttes, but perhaps it is'nt your real goal. You are currently "stuck" in 640x480, but perhaps its time to free your mind , ML can do other aspect ratio that be be used to get more than 9000 frames in 3 minuttes. There is a calculator out there to guide you :  https://rawcalculator.netlify.app/calculator_desktop  This calculator says the 60D has a 285 MB buffer, 21 MB write speed and max 60 fps (CROP MODE), the calculator is not 100% precise but its good. So what is the max fps you can get in 3 minuttes ?. That is the fps were you utilize the entire buffers before the camera memory is full and the camers stops, after presicely 3 minuttes.

Set

• the resolution to 640
• aspect ratio 4:3
• crop mode
• 43 fps (custom)

You will see that the max recording time is 4 minuttes and 45 seconds.  In three minuttes you'll get 43*3*60 = 7740 frames.

Set

• the resolution to 640
• aspect ratio 1.85:1 (640x346)
• crop mode
• 60 fps (custom)

You will see that the max recording time is 3 minuttes and 57 seconds.  In three minuttes you'll get 60*3*60 = 10800 frames.

But the real format is the one that fits the planet or object that you need to capture. Clear Skies !

(And accordingly to the https://docs.google.com/spreadsheets/d/16cgnRivbUv7nA9PUlCLmLdir3gXdIN3pqzCNAAybepc/edit#gid=3 60D should be capable of going up to 60 fps in CROP mode)

There might be is an additional way of getting a few extra buffers for recording  , simply by doing allocation reserved. It seems (?) due to history that the allocating was done firstly using shoot_malloc allocation and the srm_malloc memory allocation. The shoot config allocation allocate memory but each buffer is much smaller than the full size 14 bits buffers (srm_malloc). So basically we're getting much more memory fragmentation than needed. By using the allocation in the reverse order memorhy fragmentation become much smaller, i.e. we have more big buffer and few smaller onces. The optimal case would be to allocate the entire memory as one blob, but I have'nt seen anyone being capable of that(?). The debug memory info is run by guess_free_mem_task which first allocated shoot config and then allocates using srm (the same happens in mlv_lite and mlv_rec). It's possible to do this in the reversed order.

The total ammount of buffer than can be allocated is :

Buffers = ammout_shoot_config_buffer * round_down(shoot_config_buffer_size / (framesize+overhead)) +
         ammout_raw_buffer * round_down(raw_buffer_size / (framesize+overhead))
      
Examples:
On the 40D the srm buffers are 18153360 bytes (width*height*14/8) while the shoot config buffer are only 4194304 bytes (0x400000). Now it'll be clear to anyone that shooting with a frame size of a little more than the half size of the shoot config is a very bad idea, because we waste alot of memory, but it the size is just a little smaller than the 1/8 of the buffers size (or 1/4,1/2,1/1), then it's a really good idea. Bascially it depend on the frame size.

It's just a lot of additional programming for a few buffers ?

Btw. on the 40D I also get an additional srm RAW buffer if I only select "JPEG"

Congrats, and also nice to see that the ML community was willing to spend the money on this.

Hi all, lots of good advices so far, and it's ok to be bias'ed as long as theres a reason. I will not comment on each post, but I see mainly 3 requirements I need to address.

Community momentum.
In the recent years Canon have unleashed a high number of different cameras, making it harder for us all to keep momentum. I guess names_are_hard nail'ed it down to D678X. Since most of development is taking place around D7,D8, this is where we as a comminity will gain the most. Also since I only have limited time to spend on the project it will be difficult for me to carry the D6 development on by shoulders. There are a many nice entry level camera with D4,D5, but the future is changing.

Trends
The digital single lens reflex era is comming in an end. Canon has still to release is last flagship(?), while others like 5D and 7D seires will be discontinued. The future is mirrorless, so from that perspective, I think it would be wise to choose a mirror less unit.

Personal ideas
It would be fun to have a fullframe camera for astrophotography, but most of the time (99%) will be spend in video mode where APS-C is just fine, and purchasing a lesser expensive unit would make it possible for me to get some additional stuff.

Canon M50 (D8) - might be a solution ?
Like some have mentioned in this thread, M50 might be the right one. Just look a ZEEKs videos, were he's squeezing every last drop of blood out of the ML build for the EOS-M's, looks great and fun, what a pleasure to watch. The Next camera line missing a ML is the M50, with the "crippled" 4K video mode and many other stupidities. Reminds me about .. never buy a Camera what implements a "new feature" for the very first time, because it's going to suck. Never the less, the M50 it looks really interessing. Wikipedia also states differences between the M50 and M50 MKII :  "internal and external components are the same", which could make a future ML for M50 MKII a easy job. Also last but not least kitor did a speedrun on the M50, getting menu's up and running.

Hi all.

I have'nt been programming for a while, progres on the 40D is equal to none. The open beta ML version is 70% done, the reason being the camera is old, different from the newer camera, and last but not least, the camera model is really old. I have learned alot about ML firmware, and I think it's time to utilize this and move on to a newer unsupported camera.

I would like to hear from other people which camera would be interessing to get into the ML "program". I'm not in a rush, as I need to sell some old HAM gear inorder to get additional cash, but I would estimate I can spend around 800€ on a camera body. Timeline for getting a new body is approx 31th of December 2022.

Which camera's are interessing for this budget, and why ?

Hi Kidkoala83, thanks for testing the build!.

I have seen the blueish/snow/half mirror snow effect from time to time on my camera, and it's surely my ML build that does it. I also see these issues on test builds where I mess around with timing. I don't see it currently, but it might just be that I have coded the build to fix perfectly to my camera but not yours. Its timing related becuase I have hijacked all driver functions that writes to the peripherals (sensor, cf, display ... ect). I don't have another build currently, but the next build I will optimize and change the code and hopefully the issues will go away.

Currently I'm stuck for the 2-3 weeks, due to the war in Ukraine, my office is occupied by a grow up daugther of one of our friends from Ukraine. I have the YUV path running correctly and "just" need the jpeg path hacked and then the camera can do 1288 x 820 recording.

Hi

What does the SRM acronym stand for?

No idea, but the "SRM_" name originates from the firmware itself.

The closest I get to 924x388 is 928x388 at 2.39:1 .. What aspect ratio are you using? Or it might have been a typo..

The 924x388 is properly just a typo, my mistake.

The Blueish cold temperature screen, snow, or half-half screen effect shows on liveview, it does disappear if you turn it off and on again, at least temporarily.

Do you get these effect in LiveView even without recording ?

Haven't tried the x5, x10 zoom yet.. Should I be recording with zoom on?

When you go into zoom mode, mlv_lite is not recording in "zoom mode", but rather the raw sensor (not binning mode), mlv_lite for 40D can currently recording around 1920(?) x 806(?), but the crop mode is high and aspect ratio around 2.39

1. try to disable Small hacks
2. try to recording in zoom mode.

[Small hacks]

If I go as low as 640x160 and 5:1 or 4:1 aspect ratio i get continous mode in green letters, that seems good..
Under heavier loads i get blueish cold temperature screen, or snow, or splat screen half-half mirror effect..
How do you get those non standard resolutions of 924x388?
Do you use fps overrride to set the 24 fps?
What do "Use SRM job memory" and "Small hacks" do? How can I load the mlv_play module for playback?
I am enjoying very much testing the video on the 40d.

Hi.

Small hacks = disable white balance, disable auto exposure, tweak CF card.
Use SRM job memory = use photo memory for capturing (without SRM you are limited to 40MB buffers, with SRM > 200 MB)
mlv_play = bugged, does'nt work yet, use MLVapp.

Yes I shoot at 24 fps, I can shoot any size that the camera allows without issues.

What happens if you recording zoom mode (x5,x10).
What CF card are you using ? (old or new?)
Does the blueish cold temperature screen or snow, some slowly while recording, or does it appear when you start LiveView ?
Does the blueish cold temperature screen or snow disapeer if you close and re-open LiveView ?

Blueish cold temperature screen or snow, is a typical indication that the video timing becomes screwed.

Ok, MLV app is working like a charm, thanks!
My vids are quiet buggy though, in the other hand they were my first try with raw video..
Contrast seems really hight, sometimes the screen just fades to black.
Still amazing to have been able to record some vid with the 40D!
Looking forward to mjpeg.

Why does my image fade to black when recording raw video? Could that be bad for my CMOS sensor or something? Should I stop the vid when that happens?

Hi kidkoala83.

I did a quick one minute mlv_lite recording test using 1.0.6, format 924x388@24 fps, and did not see any issues. Im shooting in mode "M". Try to record a video with and without "small hacks" option to see if this changes anything.

Hi.

Some interessing info regarding the process on mjpeg recording.

After alot of testing, I have finally completed a proof of concept that I can change the HD image (YUV Path) and 40D's internal JPEG path in such away that we can get proper MJPEG video recording at a bitrate of approx 12-14 MB/s.  The previous video (see posts above) was using standard HD images 1024 x 680 in x1 mode (binning x3), but by changing the YUV path into it's real original size I now have a format of 1288 x 820 (non-stretched). I known this is'nt going to make any real different, but the real goal is'nt x1 mode, the real goal is zoom mode where we don't have any binning (x5,x10) and where we can read the sensor pixel by pixel. On top of that, zoom mode x5 and x10 have by default set into 1944x806 mode, that FULL HD 1:2.39. The only thing I have not been able to test/control yet is the jpeg quality, which is really important when I reach FULL HD quality. Currently the quality on the HD image is really too high (lossless ?) and I need learn to lower it, inorder to get enought recording time at 1944x806.

To get 1288 x 820 I changed the following registers (including hijacking YUV buffers pointer and EDMAC's):

0xc0f1154c  // HD stretch register format (xxxx | yyyy), when xxxx=yyyy, ratio => 1.00
0xc0f1150c  // HD stretch register format (xxxx | yyyy), when xxxx=yyyy, ratio => 1.00
0xc0f11518  // HD width = 1288-1
0xc0f1155c  // 850 | HD width
   
I will work towards a release with 1288 x 820 MJPEG recording capabilities and after that I will go for 1920x806.

Here is a 1288 x 820 luminance test image, the image has some artifacts, but I was using singlebuffering and the save function was really slow, but still proof of concept , click on the image to expand to full size.

[Happy new year !]

Happy new year !

I fought in 2021 Q3/Q4 with Ant123's jpeg motion video module, spend days on getting it to run, but could'nt resolve a bug causing drops, but now it's running in a prototype version. Current capabilities on 40D is 1024x680@max 30 fps, here a teaser at 1024x680@24fps:

SD (rubbish) resolution youtube video:

I will work toward a minor release with this module, ETA somehere in 2022@Q1. There still alot todo, stay tuned ..

I Guess I need to do a better install video next week, currently im om Mallorca 

There are a couple things that I don't understand. E.g the code works if I modify ptp-chdk.c/h code replacing it with my own code in the src folder, but exactly the same code does not work as a module. I simplified the code removing all code but the version and the shooter code(3 lines of code) and the problem remains: As a module the ptp code does not work, the handler is not activated, but in src it does.

Hi.

Post the mini module code please. Modules are installed runtime and called via hooks runtime. Your metadata section needs to be correct.

Great work. The idea of doing commerial Ads with a T4i running ML is cool  . 

For the module context, since we control the source and are compiling it, I think using -mlong-calls is an appropriate fix.  For patching at runtime, that won't work and you might need to do what you're describing.  I guess that's the context you need to work in, so you can't use -mlong-calls?  Do modules work on 1300D?  If DryOS code is far from heap alloc region, I think they won't, and I also think that my fix will work for you.

I'd like someone with better experience with ARM to confirm -mlong-calls makes sense for where I'm using it - any volunteers?

I'm not doing any runtime patches yet on 200D, they haven't been needed.  I'm assuming I'll use MMU remapping when it gets to that (or, if I'm lucky, overwriting a thunked function, the 200D has *some* code in RWX pages).

I think the -mlong-calls trick is the way to go, the optimization gained by using relative jumps is ussless.

I dont know if modules are running on the 1300D, I just worked out a solution for hijacking firmware functions, where you patch a single instruction, and you're right about that the heap alloc region need to be close, aka within +/-32MB from canon firmware (99%). 

I'll ask citrix to read this thread

"+/-32 MB near jump issue" : This is (I guess) the problem that all new cameras will face. It's also on the 1300D. On 1300D you can not hijack any calls as the addresses (csanon firmware) are further away than +/-32MB from the magic lantern firmware. I recreated a patch function that instead of using a single near jump, uses a near jump that jumps into a long call jump. Maybe this problem is also present on DIGIC7? ... if so a *temporary* solution is present in the 1300D thread.

Last update stops at 1.0.6.

Next update will be in 2022/2023. I ran out of luck (time), RL is taking all my time, shit happens once a while.

I'll be watching this thread and ML forum until then.

Open beta update (1.0.6).

https://www.magiclantern.fm/forum/index.php?topic=1452.msg224594#msg224594

With the memory system nearly completed, its time for another beta release, as mlv_lite can utilize this. This improves the recording capabilites abit.

Memory system:
* SRM compatible function implemented inorder to avoid new code, I used [SBF]CreateSharedBuffer for allocation.
* malloc fully supported in fio_malloc (get free region fixed)
* Largest shoot malloc block is around 4MB, fio_malloc updated to pass allocation to SRM above 4 MB.
* Disabled memory analysis overlay (debug menu), it will crash the camera (overlay width,height incorrect?)

Bug fixes / minor changes:
* CACHEABLE() & UNCACHEABLE() changed due to incompatible between digic4 and digic3.
* edmac channels now switch automatically between 0x4 and 0x5
* console now uses FONT_MED due to low resolution display, and included more options and buffering
* FIO_SeekSkipFile interface corrected and FIO_CreateFileorAppend corrected.
* FIO_WriteFile wrapper not checking for digic4 uncacheable pointers correctly

mlv_lite:
* mlv_lite can now allocate ~208 MB, instead of ~40 MB
* srm memory allocation enabled (if set true in menu)
* pre-recording disabled - will prevent camera from recording correctly
* Starting and stopping LiveView multiple times may set preview=black, resolve this by power off and on.

"thumbs up" 

Regardless what I did, copy scripts into ghidra script paths, or just running from ghidra2dwarfs directory, I get ImportError.
I ran ghidra2draw headless (on my 40D.elf) from bash prompt and got:

Traceback (most recent call last):
  File /home/heder/magic-root/ghidra/ghidra2dwarf/src/gd.py, line 1088, in <module>
    add_debug_info()
  File /home/heder/magic-root/ghidra/ghidra2dwarf/src/gd.py, line 132, in add_debug_info
    add_function(cu, f, file_index)
  File /home/heder/magic-root/ghidra/ghidra2dwarf/src/gd.py, line 316, in add_function
    d = res.decompiledFunction.c
AttributeError: 'NoneType' object has no attribute 'c'
INFO  ANALYZING changes made by post scripts: /ROM1.elf (HeadlessAnalyzer)
INFO  REPORT: Post-analysis succeeded for file: /ROM1.elf (HeadlessAnalyzer)
INFO  REPORT: Save succeeded for processed file: /ROM1.elf (HeadlessAnalyzer)

I have'nt had the time to analyze the failure cause.

Was your "ordinary python issue" this?
orig_base is None because the file Ghidra is working from is not ELF.  The ROM file was never an ELF, so, we may have to create one (from within Ghidra?).

I got ... "ImportError" on elf.py, so I neded up forcing all code from elf.py into the ghidra2dwarf script, python refused to find elf.py.


Here is my conversion from rom to elf

Code Select Expand



# strip the first 0x10000, entry is at 0xff810000, and remove the useless end part
cp ROM1.BIN ROM_tmp0.BIN
truncate -s 8388608 ROM_tmp0.BIN
dd if="ROM_tmp0.BIN" of="ROM_tmp1.BIN" bs=65536 skip=1
arm-none-eabi-objcopy --input-target=binary ROM_tmp1.BIN --output-target=elf32-littlearm -B ARM --change-addresses=0xff800000 --rename-section .data=.text ROM1.elf


and I tested this on my bootloader which was a success, but on the real 40D ROM/elf file it failed.

Breif update.

After fixing a ordinary python issue in the ghidra2dwarf module, then learning how to re-create ELF files the properly way (ghidra and ghidra2dwarf wants proper ELF files) it looks good. 

I took the stripped flat binary bootloader thats is used on the 40D, recreated a ELF file, loaded it into ghidra, analysed it, and then ran the ghidra2dwarf pluging, and got a ELF file with dwarf symbols and the ghidra decompiled source code. The ghidra source code ain't that bad after all, its looks abit like the real source code. Next step is try this on 40D ROM1.BIN, and the try to get GDB to load the dwarf information so we can debug with the ghidra source code in QEMU.