Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - theBilalFakhouri

Pages: [1] 2 3 ... 34
-Update: 190 USDT raised from four people.
We are 55% of the goal!

-Goal: ~343 USDT.
-All Cryptocurrencies are accepted (PM me).

PayPal are accepted too!
Please contact me on reddit or Discord (thebilalfakhouri#1803), or Facebook or Twitter for PayPal details. and don't forget to hit like and subscribe button :P

-What it's all about x2:

Found Levas's problem and notes for Dual ISO. I have never read them before :P.

Anyway a dedicated thread explain this problem is here, it appears to affect all models which support Dual ISO.

Cool. I think @levas solved it similarly. I started some fps fixes a while ago but left it undone   8)

Thanks, hmm maybe I missed @Levas experiments?, where I can read about it? :P

New builds are posted for 650D/700D which include Dual-ISO flicker fix.

New builds are posted in the first post for 650D/700D:



-Added "Fix Dual-ISO flicker" option in "Crop mode" submenu, this option will remove waterfall effect for Dual-ISO lines by reducing FPS a tiny bit, this option will work in all "Crop mode" presets except for "Full-Res LiveView" preset.
This option is enabled by default and will only have effect when Dual-ISO is enabled.

-Adjusted analog gain for lower bit-depths, now it's accurate. LiveView brightness is identical among 12/11/10/9/8 bit-depths, it was a bit off, now it's accurate.
-Added 11-bit option, it can be a sweet spot for some resolutions.

-Added  LVICV_ReleaseResource hack:

You can find it in RAW video submenu, under "Two more hacks":
"1" enables CartridgeCancel a.k.a "One more hack" before.
"1 + 2" enables both CartridgeCancel and LVICV_ReleaseResource.

Please note: that LVICV_ReleaseResource hack may result in worse write speed performance, please make your own tests and see if it's actually enhance write speed or not, if not, it's better to avoid it and use only "1" option.

-Added DISO block, I took it from crop_rec_4k_mlv_snd branch, now you will have Dual ISO info inside MLV file and you can view it using MLVApp:

DISO" border="0

-Dual ISO would be disabled in x10 mode automatically, to be used for focusing.

-Added 11-bitdepth option.
-Adjusted analog gain and LiveView brightness, now it's accurate.
-Detect binning mode change, LiveView will refresh automatically after you change binning mode.

Source code is also updated:
magic-lantern-bilal (25-5-2022).7z (crop_rec_4k branch)

Sorry I tried to convert it to git, but I encountered errors and the process failed, will try again later.

it seems @Moderators are taking a bit long time to approve new posts, see, I think I should claim a moderator role  :P or at least the ability to see pending posts.

Already answered on reddit. Feel free to continue chatting here.

General Development / Re: LiveView hacks (write speed improvement)
« on: Yesterday at 07:56:52 AM »
Found another hack which appear to disable LVICV task which saves a little CPU and memory cycles, I completely don't know what this task does:

LVICV_ReleaseResource: during my tests this hack seems not very reliable (at least on my 700D, didn't make tests on 5D3), sometime I can record more frames with this hack enabled, sometime recording time becomes shorter and it's better to not use it, however card benchmarks appear to have little improvement and the improvement is constant (unlike when RAW video recording):

no hacks:                                                                                                     only LVICV_ReleaseResource:

Around ~1.9 MB/s more, but . . but . . I was about to post benchmarks with all previous hacks with LVICV_ReleaseResource, and . . write speed was identical (huh, I remember it was about ~ 1 MB/s increase during my initial tests some days ago), anyway read first general note down below.

General notes:
-It seems there is some kind of curve for write speed improvement, once we reach higher write speeds, the effect of a new hack become lower, e.g. if you applied only LVICV_ReleaseResource hack and run benchmarks you can get ~2 MB/s improvement, but when you apply LVICV_ReleaseResource hack beside all previous hacks the gain is only ~1 MB/s (same applies for other hacks).

-My Sandisk Extreme PRO UHS-I U3 170 MB/s SDXC card version (which I made these tests using it) is limited to ~90 MB/s maximum write speed, while other versions can go up to 98 MB/s (@Walter Hmm was that an Sandisk card?), but this card is for sure a Sandisk card and it performs 99 MB/s write speed, same as my old 32GB Sandisk Extreme PRO 95MB/s UHS-I U3 SD card (second photo), but that card wasn't stable for me at 240 MHz, anyway, what I am trying to say we actually can reach:

*~90MB/s write speed in LiveView! 8)
so basically 3K 3072x1308 @ 23.976 FPS at 10-bit lossless is Continuous :P

*Only when using certain versions of Sandisk Extreme PRO UHS-I U3 170 MB/s (probably 95MB/s too) cards which reach 99 MB/s in benchmarks in Play mode. I think @Levas has 95 MB/s version? and it's stable at 240 MHz unlike my 95 MB/s version, I think it's time to me to get new card (is there a way to know it would perform 99 MB/s write speed before buying it? :P).

Code: [Select]
0xff0d6444 700D.115
0xff0d62e0 650D.104

**Try to find them for other models**

I will include LVICV_ReleaseResource hack in my next build release for 650D/700D, to be tested.

Do you still remember this weird issue I had before?

-M03-2337 - 4.5K: Doesn't have flickering issue, can be processed in MLVApp without any problem.
-M03-2338 - 4.3K: Does have flickering issue, the flickering pattern is first frame is dark, second frame is bright, third frame is dark and so on, has flickering issue both in MLVApp and cr2hdr
-M03-2339 - 4K:    Does have flickering issue, the flickering pattern is the first two frames are dark, second two frames are bright and so on, has flickering issue both in MLVApp and cr2hdr

I figured out what was happening :):

-Let's record new Dual-ISO clips in 4.5/4.3/4K 1x3 presets using 700D and showcase the problem:

-Processed Dual-ISO clips:

4.5K                                                                                                                                                                4.3K


-Unprocessed Dual-ISO clips (zoomed in view):

4.5K                                                                                                                                                                4.3K


Have you figured it out yet?
Above flickering problem is happening because of waterfall (moving) Dual-ISO lines in both 4.3K and 4K presets, the waterfall Dual-ISO lines has also another side effect which was called crawling, crawling showcase:

Clip with Crawling                                                                                                                                      Clip without Crawling (I swear to god it's not a static picture)

(both was shot at 1736x976 with Dual-ISO enabled, cropped to 960x540 and zoomed in 140%)

-In 1x3 mode crawling is there but it's minimum compared to 1080p 3x3 mode, because of high vertical resolution.

-So how we can control Dual-ISO lines and make it static (remove waterfall effect)?

I have looked closely into 4.5K/4.3K/4K 1x3 presets, and found out that certain values for Timer B register will cause Dual-ISO waterfall effect :), some values will make waterfall effect faster/slower (that's explain above flickering patterns in 4.3K/4K clips) and other values will make Dual-ISO lines completely static like 4.5K preset.

It seems a1ex has mentioned before that tweaking FPS would solve crawling issue:
To avoid the "crawling" artifacts, tweak the FPS. IIRC, at 25.000 fps it's OK.

But he wasn't very specific about Timer B and moving Dual-ISO lines. 1080p25 mode doesn't have Dual-ISO lines waterfall out of the box (Timer B value there produces static Dual-ISO lines) which will work without crawling artifacts.

For other framerates like 23.976 and 29.970 which both have waterfall effect:

-1080p24: FPS swings among 23.973 and 23.983, Timer B value swings among 2528 and 2527, enabling FPS override and setting it to 23.976 will lock FPS to 23.973 and Timer B to 2528 --> waterfall effect is removed (Dual-ISO lines are static) which means this would solve both crawling and flickering issues.

-1080p30: FPS swings among 29.958 and 29.973, Timer B value swings among 2023 and 2022, enabling FPS override and setting it to 29.970 will lock FPS to 29.973 and Timer B to 2022 --> won't remove waterfall effect --> Increasing FPS Timer B from FPS override submenu to 2024 which make FPS 29.943 removes waterfall effect.

So what's needed is just reducing FPS few steps and would remove waterfall effect, same things worked with 4.3K/4K 1x3 presets and others.

Other solutions for waterfall effect which may work:

-Very easy: Increase FPS Timer B a little bit (my way), probably decreasing it a tiny bit instead of increasing it may work too.
Can be implemented directly e.g. for crop_rec presets, just you need to find right FPS Timer values by trial and error. Stay tuned for my next build release for 650D/700D ;).

-Medium: Reverse Base-ISO and Second-ISO depending on FPS Timer B value every X number of frames, I have not tested this, can't see why it won't work. I think there is a formula for FPS Timer B could be written.

-Difficult: fix it in post :D, flickering issue caused by waterfall effect could be fixed fairly easy (just guessing), but crawling artifact would be a lot harder.

General notes:
-Flickering issue caused by waterfall Dual-ISO lines is more visible at aggressive Dual ISO setting like 100/1600 and 100/3200. setting like 100/400 would have minimum to no flickering (probably same applies for crawling, didn't make much tests).
-There are other flickering issues caused by Dual-ISO processing algorithm because it was designed for Dual ISO photos in the first place, not videos . . this flickering problem related to some parameters like white level and probably other things (same as when processing RAW video with ACR, at certain settings you will have some flickering).

Other flickering issue is probably related to how MLVApp handle Dual-ISO clips with reduced bit-depths like 12/10 bit, these two flickering issues probably won't be presented with latest version of cr2hdr and when using 14-bit lossless clips, and might only happen when processing Dual-ISO clips using MLVApp, to be tested later. (I haven't made any tests yet), I will share example to showcase these flickering issues in future.

-The only advantage I can see for waterfall Dual-ISO lines is the ability to recover full resolution image for Time-lapses (static subjects), needs special algorithm for that.

-4.3K 1x3 preset:
100/3200 Dual ISO, pushed 3.5 stops in MLVApp.

-Sorry for "witt" typo in 0:06, I meant "with".

Dual-ISO has just become more practical in RAW video :D

Yup this 99% true. As I remember decoding and raw corrections of the frame happens in a separate thread but then debayering and color processing is done as multithreaded.

I don't know how MLVApp code works, never looked into it.
But in theory if we re-write the code somehow so it could utilize more threads for decoding and raw correction then we may have faster playback, would be that possible or *some parts of processing must be single threaded?

*Even if it's must be single threaded, I guess we can process multiple frames at the same time (multi processing), e.g. each frame uses one thread or two frames per thread:
First frame would be processed on CORE 0 while second frame is being processed on CORE 1 and so one for other cores, when CORE 0 finishes, it would load the next frame which we need to process.

I have ~16 FPS playback speed using MLVApp 1.13 (default settings, Bilinear debayer) on Ryzen 3900x, Clip used: UHD 1280x2160 10-bit lossless 23.976 FPS
CPU utilization: is only ~17%
Using Amaze debayer it's ~33% (~11 FPS)

I opened two copies of MLVApp, opened same clip, used default settings (Bilinear debayer), playback for each copy ~16 FPS, CPU utilization is ~35%, multi processing theory works, total ~32 FPS playback speed :D and there is 65% of CPU power left.

What I am saying in short:
There is a room for enhancement, even if this mean re-writing MLVApp from scratch. I bet someone from MLVApp team would do that :P (seems a lot of work).

That's why we should start dedicated Patreon account for MLVApp, if one (or two/all) of MLVApp team feels he can improve MLVApp but can't do it for free (fully understandable), funding is a solution for that. I think a lot of users would fund such thing beside there is no legal concerns. if MLVApp team don't want to work on MLVApp for whatever reason (again, it's fully understandable), the idea of creating Patreon account for MLVApp lives, but instead we may hire a freelancer.
@theBilalFakhouri: did you mean he was more creative while using his good, old 5d2? :D

I did not mean that, just meant some beautiful MLV clips and used 5D3/EOSM as example (masc seems to have nice MLV clips, and looks good out of the box in MLVApp I guess), I forgot about masc owned 5D2 before :P, I don't think I have watched 5D2 clips from masc (or I just don't remember how it was). Of course clips from 5D2 would be ideal too, to be used for uncompressed MLV benchmarking :D

160 threads xeon quad cpu server/workstation only gave 8 fps playback with default settings? ..

Single thread performance seems much more important than multi threaded for playback. e.g. the lowest M1 Macbook destroys my Ryzen 3900x in terms of single thread performance (~30% faster) --> M1 has faster playback speed.
I can do some playback/exporting tests if there some unified MLV clips so other users can also make same tests with same clips on their systems.

@masc You have shot some amazing clips before using 5D3/EOS M, it would be cool if you shorten some of them and upload them somewhere (if you still have them and don't mind :) ).

It would be cool to see a set of results across a lot of different systems.
Absolutely agree.

I suggest someone to record few MLV clips in different resolutions/modes and upload them somewhere. To be used for benchmarking by users by exporting the clips in some compressed codecs like H2.64 and ProRes and *writing down processing time for each clip, then posting results in a dedicated thread in the forum (or maybe create a section in domain for posting results in an organized way).

*Could we implement function in MLVApp that saves MLV info, used codec, system info and processing time for each MLV clip to a log file? that's could be useful too.

I understand you...

Yeah, I know that :)
That reply was to for other users to stop confusion.

I hope liveview is not broken

LiveView will be stretched in "anamorphic" modes on 5D3, that's how it works currently.

Unfortunately, nothing to do right now. You need to use "Framing" preview from RAW video submenu, but, as far as I know "Framing" preview won't work with HDMI as in your case.

You need to stick with LCD screen if you want to use crop mode presets with high resolutions (which doesn't have correct real-time preview).

General Development / Re: LiveView hacks (write speed improvement)
« on: May 19, 2022, 12:13:22 AM »
Updated links in the first post for 5D3 and EOSM to Danne's downloads page.

It seems Danne added a delay after calling CartridgeCancel, please test latest Danne build for 5D3 and see if there is a first frame corruption when using "One more hack".

Sorry for the delay, my notes has been posted here.

TL;DR: A lot of time and effort would be required, but I think it's possible.

Reverse Engineering / Re: LiveView Investigation
« on: May 18, 2022, 07:55:37 PM »
-My notes for 5D3 (where to start looking):

-I have started looking in my 700D between x5 and x10 modes, and identify cropping registers by using adtg_gui module. On 5D3 I couldn't see registers between x5 and x10 mode, a1ex has mentioned that cropping is happening using Eeko core (second core for DIGIC 5). adtg_gui won't help here.

So in this case you need to capture DebugMsg log from 5D3, between x5 and x10 mode. And look for the functions which being called, try to identify which one crops the image.
Try for example do x15 cropping instead of x10 using the discovered functions, maybe play with some registers related to cropping if you found any.

Cropping functions/registers between x5 and x10 might not be needed, because it might help with only increasing the cropped area, not decreasing it. If it were required to decrease cropping then understanding it would be important.

-Compare 1080p mode against 720p. adtg_gui would show registers between the two modes. try to understand the registers and identify its effect.
in 1080p mode 1920x1280 RAW data is being processed in LiveView
in 720p mode 1920x648 RAW data is being processed in LiveView

From 720p mode set Binning mode to 3x3, increase RAW data to 1920x1280 (using adtg_gui, take the values from 1080p mode), no you will have stretched LiveView as in 1x3 mode in 5D3, try to recover the cropped part (bottom part of the frame) from your the registers you have found out (I couldn't do it on 700D, LiveView freezes).

-Compare 1080p mode vs x5 mode, a lot of registers would presented here, probably a part of these presented registers are all of what you need. Well, you need to figure out how they work togather.

-Try to identify YUV scaling registers, e.g.
In 720p RAW data would be down scaled from 1920x648 to 1280x720 in LiveView (YUV HD stream).

In 1080p 1920x1280 RAW data is being down scaled to 1904x1151
In LiveView Photo mode 1920x1280 RAW data is being down scaled to 1620x1080, in this case capture DebugMsg log between LiveView photo mode and 1080p mode, this way you might identify YUV scaling registers (on 700D I skipped these registers, doesn't help with increasing processed RAW data in LiveView).

-No idea if there other easier way, probably looking into *SetVram/ClearVram functions (in ROM1.BIN using Ghidra) in different LiveView modes. comparing them might help.
-*on 700D all preview registers are being set after calling SetVramPath (each video mode has its own SetVramPath, see strings in ROM).

-Probably most important thing is to LOG Eeko core activity, as far as I know we don't log its activity currently, would be there new range of registers? no idea.
-I think on 700D Eeko is being used too (not as much as 5D3), e.g. for centering YUV paths on screen, look at this experiment, in that experiment preview was showing in the top of screen, not centered, even though I applied patched all registers from movie crop mode to x5 mode using adtg_gui.

-Update: 160 190 USDT raised from three four people.
Almost more than half-way.

+there is in an equivalent to 50 USDT offered, we need help from someone familiar with Crypto and located in EU, please contact me if someone can help.

-Goal: ~343 USDT.
-All Cryptocurrencies are accepted (PM me).

I might be able to receive PayPal too, contact me on reddit or Discord (thebilalfakhouri#1803) for PayPal.

-What it's all about:

Got it working:

It-s-working-WSL2" border="0

As I guessed, DISPLAY configuration has changed in WSL2, followed these guides:

My IP was different: instead of "".

Followed g3gg0 guide from the first post, didn't have problems with packages, and I was able to compile ML and QEMU successfully, very fast compiling speed compared to Cygwin :)

However I am getting this error after trying to run QEMU:
Code: [Select]
gtk initialization failed
Already installed all required packages and doubled checked that, I installed and tried many X servers (VcXsrv, cygwin x, XMING, and I didn't forget to launch it) then followed these commands:

Code: [Select]
export DISPLAY=:0
./ 700D,firmware="boot=0"

Code: [Select]
DISPLAY=:0 ./ 700D,firmware="boot=0"
without a luck, same result:
Code: [Select]
./ 700D,firmware=boot=0

DebugMsg=0x395C (from GDB script)
Lockdown read 4
Lockdown read 4
Lockdown read 5
Lockdown read 5
Lockdown read 0
Lockdown read 0
Lockdown read 1
Lockdown read 1
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 0FFFFFFF: eos.ram
40001000 - 4FFFFFFF: eos.ram_uncached
F8000000 - F8FFFFFF: eos.rom1
F9000000 - F9FFFFFF: eos.rom1_mirror
FA000000 - FAFFFFFF: eos.rom1_mirror
FB000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FCFFFFFF: eos.rom1_mirror
FD000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FEFFFFFF: eos.rom1_mirror
FF000000 - FFFFFFFF: eos.rom1_mirror
C0000000 - DFFFFFFF: eos.mmio
[EOS] loading './700D/ROM1.BIN' to 0xF8000000-0xF8FFFFFF
[EOS] loading './700D/SFDATA.BIN' as serial flash, size=0x800000
[MPU] warning: non-empty spell #36 (PROP_VIDEO_MODE) has duplicate(s): #37

[MPU] Available keys:
- Arrow keys   : Navigation
- [ and ]      : Main dial (top scrollwheel)
- SPACE        : SET
- DELETE       : guess (press only)
- M            : MENU (press only)
- P            : PLAY (press only)
- I            : INFO/DISP (press only)
- Q            : guess (press only)
- L            : LiveView (press only)
- A            : Av
- Z/X          : Zoom in/out
- Shift        : Half-shutter
- 0/9          : Mode dial (press only)
- V            : Movie mode (press only)
- B            : Open battery door
- C            : Open card door
- F10          : Power down switch
- F1           : show this help

Setting BOOTDISK flag to 0
gtk initialization failed
[MPU] WARNING: forced shutdown.

For clean shutdown, please use 'Machine -> Power Down'
(or 'system_powerdown' in QEMU monitor.)

Tried to run the following just for testing:
Code: [Select]
Code: [Select]
application-specific initialization failed: couldn't connect to display ":0"
Error in startup script: couldn't connect to display ":0"
    while executing
"load /usr/lib/x86_64-linux-gnu/ Tk"
    ("package ifneeded Tk 8.6.10" script)
    invoked from within
"package require Tk"
    (file "/usr/bin/gitk" line 10)

No idea what's the problem, I am using ubuntu distribution, WSL2 (it could be WSL version problem and how it handle DISPLAY?, I am not sure if your tests are done using WSL1 or WSL2).
Tested on Windows 10 x64 21H2 (19044.1645).

Also tried Windows CMD with bash command and Ubuntu cmd, same result. tried rebooting PC after I installed all packages and X server same thing.

Hello, cool idea :)

-Note: 1080p 1:1 (x3 crop) on 5D3 uses default 1080p preview configuration, in this mode we are not touching the preview, just the sensor Binning mode we are using 1x1 instead of 3x3.

It's possible to increase RAW resolution but increasing RAW resolution (in particular width resolution) will break the preview. We can fix broken LiveView but this only works in x5 mode. Attempting to fix preview in 1080p mode will freeze LiveView (I did try it on 700D, I am assuming 5D3 would have same result, I can make a quick try to confirm that later).

That means we need to reverse engineer LiveView and understand how preview works on 5D3 just to achieve this simple goal; I mean a lot of time and effort are required :(.
We might not be able to achieve this goal anytime soon (or maybe *at all). I am working on 5D3 preview from time to time, but there is no real progress, can't promise anything. I often have to stop working for months.

On 700D we can already control preview in x5 mode, and I could made 1920x1280p 1:1 preset with correct preview (instead of default movie crop mode 1800x1012). Well, I still can't control preview in 1080p on 700D, attempting to play with preview configuration in 1080p mode freezes LiveView.

I can give some info about how to start reverse engineering preview on 5D3, a lot of work/time are required, let me know if you are interested :)

*Simply there are no active developers who are working on these old models (DIGIC 4/5), and in general the interest now is to port ML to new models (DIGIC 6/7/8).

General Development / Re: LiveView hacks (write speed improvement)
« on: May 09, 2022, 03:59:38 PM »
Yeah, I simply can't turn off the console all time (or even only when RAW video recording). It's used mostly in every ML feature, disabling it is not a good idea at all, you may have corrupted frames while recording without realizing that which result in totally useless MLV clip.

I didn't have console showing when I used "One more hack". Could you share your settings? a steps to reproduce?
-Probably adding a little more delay after calling "One more hack" could solve this problem. I will do it soon.

-In general: avoiding using "One more hack" could be a better idea for now, since I really don't know what is it doing (this hack actually disables some EDMAC channels activity), figuring out how to silence EDMAC channels streams without using CartridgeCancel a.k.a "One more hack" in clean way is a solution for the side effects we are having when using this hack.

-Edit: also mind share printed message in the console? are you sure it's from "One more hack"?
It could be from something else.

Hi again Bilal Fakhouri!

Is it somehow possible to shoot at 30 fps in the UHD 1x3, 4K 1x3 or 4.3K 1x3 modes?
Or if I set some values manually, can the 700D with all the speed hacks actually achieve this?


This was requested before, the sensor is capable but when attempting to record e.g. 1280x2160 @ 30 FPS with real-time correct preview an overhead would appear resulting in corrupted frames.

So real-time correct preview (in ~2.7 MP presets like 4.5K/4.3K/4K/UHD 1x3) with 30 FPS are no go right now.

Post-processing Workflow / Re: fastcinemadng
« on: May 03, 2022, 03:50:23 AM »
Would it be ok if it's like soft clip in Resolve?

Sorry for the delay.

I don't use Davinci Resolve much, I can't answer this question without photos comparisons. beside I think highlight roll off in Resolve varies depending on color management and color space settings . . So I don't know how we should compare it against Fast CinemaDNG.

I am asking if there is a way to achieve soft highlight roll off in Fast CinemaDNG, more like what MLVApp does in "Profiles" settings.

General Chat / Re: How did you guys know about Magic Lantern?
« on: May 03, 2022, 03:39:11 AM »
From what I remember back then in 2016-2017 I was watching YT videos which were comparing DR among H.264 standard profile vs H.264 CineStyle then YT recommended H.264 CineStyle vs RAW video comparisons in term of DR, and I was impressed by the results. and after that I started digging into Magic Lantern thing.

General Development / Re: LiveView hacks (write speed improvement)
« on: May 01, 2022, 10:55:54 PM »
Oh i guess its UHD awith a small decrease in the horizontal resolution?

on 5D3 set crop mode preset to UHD, from RAW video submenu set resolution to 4096 and Aspect Ratio to 16:9 so you can get 3840x1536 then highlight "Resolution" and use "Main Dial" or "Multi-Controller" to decrease resolution to 3616x1536.

Crop mode V2 is not related here, and that's only for 650D/700D.

Camera Emergency Department / Re: EOS M - Bricked, showing Err 70
« on: April 29, 2022, 04:53:07 AM »
General info:
-PROP_VIDEO_MODE is property which change Canon video mode which include some info about crop mode (disabled/enabled), FPS (24/25/30/50/60), selected resolution and maybe other info too.
-Requesting PROP_VIDEO_MODE to change video mode while we in 1080p to Movie crop mode is fine.
-Requesting PROP_VIDEO_MODE to change video mode while we in 720p to Movie crop mode --> congrats you soft-bricked your camera.

So we should be careful from which mode we request PROP_VIDEO_MODE property change.

How EOSM users are bricking their camera (like this one)?
Just use Danne build :P Just kidding, Danne builds are good.

Danne uses PROP_VIDEO_MODE request in some crop_rec presets, in some cases PROP_VIDEO_MODE is being called at wrong moments while changing crop_rec presets which result in invalid PROP_VIDEO_MODE values --> ERR70.
I think Danne has fixed this issue (didn't notice any new reported cases), so probably nothing to worry about right now when using Danne builds.

-The autoexec.bin fix from a1ex attempts to reset PROP_VIDEO_MODE to valid values (in particular 1080p24) at startup, so this tricks the camera and no crash would be triggered then the new valid settings would be saved.

Pages: [1] 2 3 ... 34