Danne's crop_rec_4k experiments for EOS M

Started by Danne, December 03, 2018, 06:10:17 PM

Previous topic - Next topic

0 Members and 9 Guests are viewing this topic.

Danne

hehe, ok, I will have to take a look at this. Maybe a bug.

masc

Quote from: ricardopt on June 19, 2019, 02:52:47 PM
i dont have much time now (work starts in a bit) but the final timelapse video is the same as a normal video recording for 6min, no difference at all.
Sure, if you don't setup fps override in MLVApp this is expected. Type e.g. 25fps in this field and you'll get what you want.
5D3.113 | EOSM.202

Danne

Just tested. Seems to work as I told you. Recorded a 3fps file for a minute and about 174 frames. Turned it off and then 7fps and around 500 frames after a minute. So speeding up the timelapse i the solution to your problem.
Maybe I can set a different metadata tag when ending recording. Will have a look on this.

masc

But to what framerate do you set then? Some person like 24, some other 25, the next guys love 30...
5D3.113 | EOSM.202

Danne

True, Either set to the same fps as set 3fps or just leave at the wrapper 7fps one.

anto


baladev


sirminder

Hi everyone, new guy here.  After seeing some of Zeek's videos, I was motivated to jump on the MLV bandwagon and got me a used EOS M.

I loaded it with Danne's ML from early in June (thanks for your work and dedication Danne!).  Also, I went ahead and got the Viltrox EF-EOS M2 Speedbooster, so I can use some of my EF lenses.

I have been doing some tests using the Canon 50mm 1.8 and I am very pleased with the results so far, but still need to go through all the settings and menus.  However, I seem to be having a battery drain issue...only when the SD card with ML is inserted.  I have been going through some of the 116 pages that are now in this thread, but I cannot find the answer to fix this.  Some people had said upgrading the firmware on the Viltrox to 1.4 fixed their problem, so made sure fw1.4 was on mine.  Still, if I leave the battery in the camera along the Viltrox attached and the ML SD card, the battery will be drained while the camera is off.

To test what the problem could be, I did the following:
- Camera Off, Viltrox w/50mm 1.8 attached, 64G ML SD Card inserted, I switched from AF to MF on Lens and back - led on camera flashes a few times = battery drain.
- Camera Off, Viltrox w/50mm 1.8 attached, NO ML SD Card inserted, I switched from AF to MF on Lens and back - NO led at all and battery keeps its charge.

Unfortunately, I do not have an EOS lens to test without the Viltrox.

Is there a menu setting that covers this? Sorry if this has already been covered before, but I am still reading through everything here.

Thanks.

ZEEK

It has nothing to do with the SD Card + ML. It's merely the Viltrox Focal Reducer that's causing the issue here (or a faulty battery). I haven't experienced the issue myself 'ever' and I own (x2) Viltrox Focal Reducers [EF-M2].

The battery draining issue caused by the Viltrox is identified here by other users of the adapter:
https://www.dpreview.com/forums/thread/4350743
EOS M

masc

My Viltrox speedbooster drains the battery too... sometimes. No idea what I could have done differently when it is drained or when not. Also the speedbooster sometimes sends wrong metadata to the EOS M. So for the EF 50mm 1.4, mostly it sends 35mm and f/1.0, bot sometimes 50mm f/1.4.
5D3.113 | EOSM.202

uEOSM

Quote from: sirminder on June 22, 2019, 11:38:44 AM
...only when the SD card with ML is inserted...
The same problem, the battery is discharged. I do not have a speedbuster, a standard 18-55 lens. From the first day I installed ML, a year ago.

ZEEK

When the Viltrox sends the wrong signal, you just detach and retach the lens and it should automatically adjust to the correct information. I cant say much on the battery draining issue as I only have one AF lens (Canon 50mm STM) and use mostly manual focus lenses. I have one Canon EF zoom with IS coming in soon so I'll see how that performs...

It is expected that any lens with electronic connection or signals sent to the  camera will decrease battery quicker than dumb adapters with manual lenses. Even my Zeiss Milvus which is full time manual focus drained the battery quicker than anything I've seen as it has electronic connections.
EOS M

masc

Yes, detach and retach helps. But even then, without changing the lens: when using the cam next time it might be wrong again...
5D3.113 | EOSM.202

a1ex

Quote from: uEOSM on June 23, 2019, 03:46:37 PM
The same problem, the battery is discharged. I do not have a speedbuster, a standard 18-55 lens. From the first day I installed ML, a year ago.

To troubleshoot this problem, try the current lua_fix build from the download page. In case of incomplete shutdown, it should keep the SD LED always on, so you should notice it right away.

That change doesn't seem to be included in Danne's builds.

Danne

Hm, I will try and merge lua fix here.
If cam was not shut down over here it showed a red light though so never had those issues. On eosm2 however...

a1ex

With the old codebase, ML turns on the LED when receiving the shutdown message. If anything turns off the LED meanwhile (such as, from a SD card write finished afterwards), the LED will remain off, even if the camera doesn't shut down completely.

This happened to me a lot more often than I've expected. During development, I've noticed that - after the shutdown signal - the LED was sometimes turned off for 1-2 seconds (and then, turned back on for a split-second, until power down). Those 1-2 seconds were long enough to make me think the shutdown was complete, when it wasn't, so I was removing the card too early. Result: corrupted filesystem, had to format the card, prepare it from scratch, yadda yadda. Eventually, that became pretty annoying, so I made this change.

With the new codebase, ML turns on the LED every 20 ms, in background, since receiving the shutdown signal. That is, as long as DryOS is still alive (and it normally is, until the MPU cuts off the power), the LED will stay on, even if some other tasks will try to turn it off.

Besides revealing incomplete shutdowns, with the new method, one is no longer tempted to remove the card before the shutdown completes.

Danne

Aight, sound very good. Will test tonight.

Speaking corrupted files I had some of that related to sd_uhs before adding back reconfiguration fix yesterday. I had to try really hard though to force patch and it was only on one card, only on 100D.

Removing card and being real abusive to my eosm testing stuff shutting it on and off, pulling card too early is rather mandatory here. However abusive there hasn't been one time a battery pull didn't fix it. I'm pretty amazed about how this works all of the time. The safety level i consider to be very high...

a1ex

QuoteHowever abusive there hasn't been one time a battery pull didn't fix it.

Heh, I could count at least two times just from your side :)

Add at least one SD card damaged by sd_uhs and one CF card damaged by my own code (which I thought to be harmless before running it).

And a bunch of other similar events that happened to other developers (dfort's EOS M, chris_overseas' 5D3 and Greg's 500D are just the ones I remember right now). In all these cases, the issue was from faulty ML code (invalid value for some property). These were recovered.

Yes, the probability of things going wrong is low, but quite a bit above zero. That applies to all ML builds.

Quote
Speaking corrupted files I had some of that related to sd_uhs before adding back reconfiguration fix yesterday.

With all the recent testing, I still consider sd_uhs extremely unreliable (based on my own experience with it). There are two major issues: one is thread safety during card reconfiguration, and the other is signal timing likely on the edge (I've got benchmarks running in LiveView, but failing outside, or viceversa, on some cards).

QuoteThe safety level i consider to be very high...

I disagree - there are so many things that could go wrong. This article gives some pretty good background info, although it's not specific to our project. This one was written back in 2012, when I didn't really know what I was doing.

The worst issue comes from the way DryOS is designed - any task can write anywhere into RAM (even on memory belonging to other tasks). Then, at shutdown, Canon code writes stuff into their persistent memories - one of them being the main ROM (that's right, they reflash the ROM at every shutdown). It's not hard to imagine a sequence of events that would result in garbage written into ROM, resulting a camera that doesn't boot. Wait, it actually happened - two years ago I've bricked quite a few 5D3's with early crop_rec_4k builds (luckily recovered all of them, to my knowledge).

So, one of my unfinished quests is to find a way to prevent Canon code form reflashing the ROM. Ideally, by disabling ROM writes at hardware level, to keep the camera safe even from reflashing code called by mistake. Current status: if you end up calling e.g. EraseSectorOfRom (even indirectly or unintentionally) with the wrong arguments, you might end up erasing the bootloader, and I won't be able to recover the camera. That didn't happen yet, to my knowledge, but it is theoretically possible.

Another thing I've started to think about lately, is how to prevent data loss in the case of hard crash, power cutoff or other stuff like that. For example, ML could create some backups of the FAT tables. I might even be able to completely undo a card format, after the fact. Or, if you record a long MLV file and there is a crash / power cutoff / whatever the middle of recording, ML should be able to recover that file at the next reboot (currently it doesn't). Or, even while transferring the files to PC, a flaky USB connection could result in data loss (it happened to me some years ago, and a backup of the FAT would have saved the day).

Sorry for the off-topic.

Danne

Quote from: a1ex on June 23, 2019, 09:18:21 PM
Heh, I could count at least two times just from your side :)

This article gives some pretty good background info, although it's not specific to our project.
Eh, two times messing with crop mode regs  :P
Besides those two mistakes no persistent damage.
Great article shared by the way. Should be read by users, recommended.

Yes, sd_uhs is a golden gem but could need some polishing. I try to but it's all pragmatically based slow understanding of how it works. Thankful for all info shared from yourself here.

sirminder

Thanks for the help and feedback. I will troubleshoot further as suggested and report back my findings.

Sent from my SM-G930F using Tapatalk


lightspeed

is it possible to get a 3.5 k mode with a 16 fps. obviously wouldn't be continuous but would be nice to have the option. 9 fps is just too low.

Danne

If you manage to decrease reg_6014 and get higher fps then it works. Or else not.

Danne

New version:
https://www.magiclantern.fm/forum/index.php?topic=9741.msg208959#msg208959

Commits:
https://bitbucket.org/Dannephoto/magic-lantern/commits/72d33da5618f5ce1d8ebfbbb5d7d897de11079c9
https://bitbucket.org/Dannephoto/magic-lantern/commits/d1672795e552aac3ce74f6155027c97faf8591ac

- Shutdown routine from lua_fix(Thanks a1ex)
- 4k timelapse preset. Added shutter blanking when working wiht 4k timelapse presets. Works like this:
Select 4k preset. In sub menu add a 4k timelapse fps preset. Now shutter blanking is applied but preview is also very slow.
Select Slow shutter on top of above and as it says shutter will be slow as the fps selected. Shutter blanking will be off. Preview will be in around 7fps so faster and easier to set up due to some workaround foolishness  :P.
Tip: 4k timelapse mode will work very good with Rec trigger set to Half-shutter: start/pause

EDIT: Noticed lua isnĀ“t compiling. Will take a look. Stay tuned.
FIXED!

2blackbar

Great work ! Im planning to buy M-EF adapter to use electric AF lenses(i have manuals ATM) i know that M was kinda failure for canon because of problems with slow autofocus but ive seen some videos with magic lantern that improved autofocusing with auto lenses a lot, is that true ?

baladev

Auto focusing with original firmware was very slow, but then Canon improved it a lot with a firmware upgrade. But, it is still CDAF which breathes a lot when focusing, so quite useless for serious work. If you need good AF, 70D is the best in this regard, it has DPAF, which is very smooth and doesn't breathe in good to moderate light.