Messages

Thanks so much for making this tool. I love it!

I've noticed that in the latest release (1.9) on my lowly 2015 MacBook 12" that memory is consumed rapidly when using the new sharpen "masking" tool. Memory usage has always hovered around 250MB but I came back to only a few files processed (successfully), a frozen batch job, a very sluggish Mac and Activity Viewer showing MLV App using over 20GB of RAM (mostly swap, of course).

Thinking perhaps my copy of MLV App was corrupt I downloaded it again, deleted all of its preference files but get the same result. Repeatable by setting "sharpen" to any value above 0 followed by "masking" to any value above 0. Default settings otherwise. Export file format does not make a difference (tested with ProRes and H.264). MLV App does not release that consumed memory after processing the files either, it hangs on to it until it is quit.

Otherwise 1.9 is just as stable as 1.8 on my machine. Thank you for all of your hard work!

I know you mentioned M2 development is stalled due to some issues not replicable in QEMU so I'd like to see about getting some grease on my hands. I'm a developer but just a young Padawan in this realm. I've been reading through the developer guides and have tried to repeat the porting process in this tread but...why reinvent the wheel? Plus it's taken nearly two years of your effort to get this far and I'm missing things not found in the thread partly due to my environment being different.

For instance, I'm using Ubuntu 16LTS on a VirtualBox machine because my Mac is heavily configured for other development work and I don't want to accidentally break it for my paying work. I did get QEMU up and running on the Mac but got endless logs and a blank gray UI with a red dot in the lower right then it would crash. Actually took my Mac with it which I rarely ever see. I decided on some separation.

Following the guide here https://www.magiclantern.fm/forum/index.php?topic=991.0 for installing magiclantern I have a sandboxed environment to play in. Seems to work just fine. However, I see no EOSM2 in the platform directory. So I tried merging in your branch (hg merge crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort) but that fails with an "unknown revision" error.

I tried from scratch using your version of the bleeding edge branch (hg clone https://bitbucket.org/daniel_fort/magic-lantern/branch/crop_rec_4k_mlv_snd_isogain_1x3_presets_EOSM2_dfort).

Renaming the resulting directory "magic-lantern" lets me complete the qemu setup process. However, if I update QEMU (hg up qemu -C) I again have no EOSM2 directory. If I don't update qemu and instead update the tip (hg update tip) then I get your EOSM2 directory in the platform folder.

I then create the gcc-arm path (PATH="$HOME/gcc-arm-none-eabi-5_4-2016q3/bin:$PATH") in .bashrc since it wouldn't work in .profile. After this I'm able to run the install.sh for qemu (the one in your branch) without a problem.

I then make magic-lantern in the ml EOSM2 directory (make clean && make install_qemu).

This updates the sd.img in the new qemu-eos directory (same level as magic-lantern directory). Seems like I'm good to go.

However, running QEMU with ./run_canon_fw.sh EOSM2 results in errors concerning the format of long unsigned int values. I've tried commenting out the code it references since they're just status updates but the more I comment, the more keep coming and I doubt this is how you're building it.

So I start over and build qemu exactly according to the instructions in the link above. Then I clone your branch as before, build the EOSM2 with make clean && make install_qemu and everything seems peachy keen. I copy my ROMs (ROM0, ROM1, SFDATA) into qemu's EOSM2 directory and again try ./run_canon_fw.sh EOSM2 but get the same gray screen I got on my Mac and it kills the virtual machine with the same endless loop of "WARN [I2C] localI2C_Write : 317 (Task : Startup)". It also spits out "[AUDIO] ERROR I2C abort 0(1020000)" repeatedly. If I kill the qemu window quickly enough then I can regain control.

I've tried various .run... commands but everything results in an endless loop or runs to a crash or runs to a lockup. I'm unable to get anything in QEMU. Since I only have the EOS M2 I can't test with any other build just to see what I'm doing wrong (no ROM files for anything else). I did order an M for comparison but it's not arrived yet.

So, I'd like to get up and running with testing in QEMU but I think I might be acting above my pay grade. I'm happy to take advice.

In the meantime I keep testing with your releases. As I understand it they are just updated syncs with the bleeding edge EOS M branch and have nothing to do with getting the M2 past its live view freezing issues. Is that a fair read?

I have the development environment configured on my machine now, am able to build but it looks like I have several tutorials to run though to get me up to speed with the typical workflow of ML development. Currently my QEMU displays a blank black screen past the date/time screen although I can see the console recording keypresses. Might have to do with my Mac or version conflicts or a myriad of other possible incompatibilities.

However, I'm not sure if QEMU is even used at this stage of development. Are you building and testing directly on the M2?

Until I'm up to speed I can only report what I'm finding as a user attempting RAW video. I'm able to record 1800x1012 in 3x crop mode in 16:9 and all the way up to the 2.5k in 5x crop mode but the 2.5k has a significant number of purple frames and is unusable. I use a 64GB SanDisk Extreme Pro with the sd hack in both cases. If I lower the resolution to 1920x872 in 5x crop (I believe it's 1:2.35) then I can record continuously. I can do these in 14bit lossless. If I use 12bit lossless then every other frame is frozen (as in either black or a repeat of the very first frame of video).

The 1800x1012 in 3x crop mode is very finicky. If I start recording immediately after the sd_uhs script completes its autorun then I have been able to record continuously without issue. However, if I wait to record for some undetermined amount of time live view freezes up. The only way I can unfreeze live view is to toggle through the 4 view modes with the Info button. There are 2 Canon GUI modes, the ML GUI then the pure settings GUI mode. I have to cycle through the settings GUI mode back to the first Canon mode and then I'll see an unfrozen live view again. However, if I don't start recording immediately it will freeze again and I have to cycle through the screens to get it back. I can play this game only two times, unfortunately. The third time all of the view modes are a blank black screen.

I've tried flipping to camera mode and back to video but once I see a blank black live view mode I have to restart the camera for video work. Fortunately I can play this game all over again after rebooting.

If there are particular files with configurations that are tedious to build and test I'm happy to build and grunt test them locally but would need to know the files and rough plan. Otherwise it will be a while before I can contribute to the freezing issue.

My post is not about the bits and bytes behind but my experience with ML on the M2 as a user. First of all, thanks so much for your work! Maybe what I've found can help you devs flush something out?

I've been testing mostly in RAW trying to use settings that seem to work for others on the M. The quirks I've noticed that might be meaningful relate to dfort's discovery of the FPS timer setting. I don't know how that was discovered but I've noticed in testing that if I do not configure the FPS timer A to 588 then I get a black band on the right side of video with my RAW settings. The band seems to vary in width depending on the frame rate I use although it is constant during any given recording.

My settings for this were as follows:

Modules loaded: mlv_lite, mlv_play, mlv_snd, sd_uhs, lua.

I then enable my M2 with "RAW video" and "FPS override". FPS override is set at 23.976 exact. RAW is set to a resolution of 1736x474 with a 1.61 crop, 14 bit lossless. I then do the 2.5k trick of going back to Canon's LiveView (LV) interface and zoom in to 5x. LV unfreezes (previously frozen) and I can view and record live motion. I go back to the ML menu and set RAW to record at 1972x872 with a 1:2 crop. This seems to work for me and I get usable footage. Looks great (MLV App with Chroma Smooth 3x3 to eliminate Focus Pixels)! However, on the right side is the banding I mentioned:



UNLESS:

I go back into the Canon LV mode and disable the 5x zoom then go into the FPS override and set the FPS timer A to the 588 mentioned. I have not tried other values to see if bands appear elsewhere if I go higher or lower. If I go back into the Canon LV and enable 5x zoom then my recordings no longer have the black band on the right. I've tried it with other resolutions and also with 24fps exact and the black band on the right is gone. I did notice that it seems to be precise amount above 588 and not 588 itself since the timer changes depending on frame rate and zoom ratio but stays a constant +64 above. 64 sounds like an address shift of some kind.

Another thing I've noticed is that the 5x zoom does not center the image. At least on mine it doesn't. Whatever I see on in LV is of course smaller than what I record but the resulting footage shows that the LV zoom, while centered on the screen (meaning the little positioning square is smack dab in the middle of its container), is off to the left of what it's recording. So much so that it looks like there's nothing recorded to the left of what I shot and double that to the right. Like this [x  ] where "x" is what I saw on LV and [] represent frame bounds. I would have expected [ x ].


The green dotted line is what I see in LV.

Maybe that's no help at all or maybe you've encountered similar or already know this. I'm happy to test anything you'd like but will need guidance if you want log files. Trying to go through the setup on my Mac for dev work but my machine is a Jenga tower of developer tools and something's not playing right and silently failing so I'll have to figure that one out before whatever the next step will be.