ArcziPL's crop_rec_4k experiments for 70D

Started by ArcziPL, March 07, 2019, 10:27:17 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

ArcziPL

Updated on 01.03.2021

Latest download link:
https://bitbucket.org/ArcziPL/downloads/downloads/magiclantern-Nightly.2021Mar01.70D112_crop_rec_4k_mlv_lite_lossless_fps_override_focus_stack_sduhs.zip

Tested:
- 1832x1024 resolution 24&25fps: works
- 720p 50fps: works
- full-frame mode: works
- 3x crop mode (this model has it available as option in the Canon menu): works
- audio: works
- Servo-AF: works
- Single-shot-AF (triggered with half-shutter): works (if small hacks disabled)
- 14-bit lossless: works
- 12-bit lossless: works
- 8..11-bit lossless: works
- focus stacking and related functions: works

All in all it looks very promising already. Here a build, so you can use and test it as well. Please feedback. :)

This build
- is based on crop_rec_4k_mlv_lite_snd
- lossless RAW video compression is enabled (thanks to a1ex for help)
- FPS override is enabled thanks to a finding of David_Hugh (there is still a small glitch)
- does include a custom variation of sd_uhs from theBilalFakhouri with selectable 160/192/240MHz presets
- focus stacking and related features are enabled, was a just a matter of activating the feature as all work was already done by a1ex
- uses #undef FEATURE_ARROW_SHORTCUTS, so this feature won't pop-up unexpectedly in LV
- does include a dualiso module with standard register addresses. For my cam I need alternative ones. You can get them here:
https://bitbucket.org/ArcziPL/downloads/downloads/70d_dual_iso_alternative_adress.zip


Disable AUDIO BEEP in Canon menu when using ML on 70D!
M50.110 [main cam] | G7X III [pocket cam] | 70D.112 [gathers dust] | M.202 [gathers dust] | waiting for M5II

DeafEyeJedi

Great stuff @ArcziPL and Thanks @a1ex for sharing your inputs on this. Definitely will get my hands onto a 70D once again and test this build out. Miss using the swivel LiveView LCD screen.
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

andy kh

good news for 70d users. did a short test. face tracking stil doesnt work well with this build. face tracking dont work as soon as i turn on my camera after installing this build. its like any other previous build when it comes to face tracking.

with the nightly build everything seems to work well until i hit record button. as soon as i hit the record button, face tracking freeze

i can record a video and share if anyone needs what i mean

edit: i did the nightly build test some months agao and  hadnt done the nightly build test properly since a friend was using my cam. i wil do more test as i have got my camera back and report
5D Mark III - 70D

Danne


andy kh

Quote from: Danne on March 08, 2019, 05:58:56 PM
Does turning off small hacks help?

i can turn off small hacks only after activating mlv lite. face tracking dont work well with this new build even if i don activate anything
5D Mark III - 70D

ArcziPL

Quote from: andy kh on March 08, 2019, 05:51:09 PM
face tracking stil doesnt work well with this build. face tracking dont work as soon as i turn on my camera after installing this build. its like any other previous build when it comes to face tracking.

with the nightly build everything seems to work well until i hit record button. as soon as i hit the record button, face tracking freeze

i can record a video and share if anyone needs what i mean
Erm, yes, recording would be nice. Seeing exactly what happens could help.

It is even more interesting because... it works for me flawless. Here I show a video where I activate face tracking and record 14-bit lossless MLV afterwards; just check it out:
https://youtu.be/BMV2jdAEJyA

Quote from: andy kh on March 08, 2019, 07:13:37 PM
i can turn off small hacks only after activating mlv lite. face tracking dont work well with this new build even if i don activate anything
What you mean by "don't activate anything"? Are any modules enabled?

Please empty your SD card completely, copy all files from my build to your SD card and put it into your camera. And that's it. This will be the starting point for the investigation and for your video showing us what happens.

I've just done it on my 70D: emptied the card (with bootflag already set), copied the content of the archive, started the cam, ML loaded for the first time (no modules were activated) and recorded h264-i 1080p 25fps with face tracking. It worked same good as on the youtube video above...
M50.110 [main cam] | G7X III [pocket cam] | 70D.112 [gathers dust] | M.202 [gathers dust] | waiting for M5II

andy kh

http://www.youtube.com/watch?v=uL4hUGSx0Nw&feature=youtu.be

here is the video.

i have been doing the test in selfie mode and here is the result. no problem without ML
it seems to work well so far if it is not in selfie mode
5D Mark III - 70D

dfort

Interesting observation -- with ML loaded the screen doesn't switch to mirror display when in "selfie mode." So it looks like the face tracking is trying to track where the face "should" be on the screen which is on the opposite side. I just took a look on my 700D and in "selfie mode" the LiveView image also does not switch to mirror mode with ML loaded. Never noticed this before. (I'm not a blogger and don't take many pictures of myself.)

yokashin

Thanks a lot!
I appreciate your hard work!
And I was about to change my 70D to M1 :)

Good luck in further work!



Quote from: ArcziPL on March 07, 2019, 09:28:28 PM
Hell yeah, first 14-bit lossless MLV from 70D! 8)



It's amazing what you know about and can do with closed internals of these cams!

The one to be commented out is
//0x5002d,

If too much was commented out (all but first four lines: EDMAC channels and read/write connections) it was still stucking at the same point and additionally locking the camera. LV couldn't be exited. After changing mode between photo/video it thrown Err80.

With only this one line removed I haven't noticed any side effects yet but wasn't focusing on it. I'll test it in the next days/weeks, report back and submit a pull request if all seems to be fine.
70D.112 [main cam] | M.202 | S110 [CHDK]

ArcziPL

Quote from: David_Hugh on September 11, 2018, 12:37:30 AMI could not see/find a C0F0 [6008], but a C0F0 [6014] and [6024] which had the same value. I needed to change BOTH of them in order for the image not to freeze. In this manner, I was able to lower the fps in the crop_rec module AND in regular 1080p, but I could only lower fps, not increase.
Bingo, good work David_Hugh! This opens the doors to FPS override on 70D. I already adapted fps-engio.c to always set both registers for Timer B adjustments according to your find. Result: FPS override finally works (ok, kind of, still one issue to be solved) and lossless compressor for MLV broke again. :P

fps-engio.c
@@ -45,6 +45,7 @@

#define FPS_REGISTER_A 0xC0F06008
#define FPS_REGISTER_B 0xC0F06014
+#define FPS_REGISTER_B_DUAL_PIXEL 0xC0F06024
#define FPS_REGISTER_CONFIRM_CHANGES 0xC0F06000

#define PACK(lo, hi) ((lo) & 0x0000FFFF) | (((hi) & 0x0000FFFF) << 16)
@@ -52,6 +53,7 @@
#define FPS_REGISTER_A_VALUE ((int) shamem_read(FPS_REGISTER_A))
#define FPS_REGISTER_A_DEFAULT_VALUE ((int) shamem_read(FPS_REGISTER_A+4))
#define FPS_REGISTER_B_VALUE ((int) shamem_read(FPS_REGISTER_B))
+#define FPS_REGISTER_B_DUAL_PIXEL_VALUE ((int) shamem_read(FPS_REGISTER_B_DUAL_PIXEL))

#ifdef CONFIG_7D
uint32_t *buf = NULL;
@@ -485,10 +487,7 @@
     float shutter = frame_duration * (max - blanking) / max;
     return (int)(1.0 / shutter * 1000);

-// ToDo: Cleanup 70D once fps override feature is fixed
-// till then use the fallback. Do it this way to have fast ettr
-// and keep frame_shutter timer enabled in consts.h
-#elif defined(FRAME_SHUTTER_TIMER) && !defined(CONFIG_70D)
+#elif defined(FRAME_SHUTTER_TIMER)
     int timer = FRAME_SHUTTER_TIMER;

     #ifdef FEATURE_SHUTTER_FINE_TUNING
@@ -750,6 +749,7 @@
         timerB -= 1;
         written_value_b = PACK(timerB, fps_reg_b_orig);
         EngDrvOutFPS(FPS_REGISTER_B, written_value_b);
+        EngDrvOutFPS(FPS_REGISTER_B_DUAL_PIXEL, written_value_b);
         fps_needs_updating = 0;
     #if defined(NEW_FPS_METHOD)
     }
@@ -1050,6 +1050,7 @@
         written_value_b = 0;
         EngDrvOutFPS(FPS_REGISTER_A, fps_reg_a_orig);
         EngDrvOutFPS(FPS_REGISTER_B, fps_reg_b_orig);
+        EngDrvOutFPS(FPS_REGISTER_B_DUAL_PIXEL, fps_reg_b_orig);
         EngDrvOutFPS(FPS_REGISTER_CONFIRM_CHANGES, 1);
     }
}
@@ -1651,6 +1652,7 @@
     {
         EngDrvOutLV(FPS_REGISTER_A, fps_timerA_override);
         EngDrvOutLV(FPS_REGISTER_B, fps_timerB_override);
+        EngDrvOutLV(FPS_REGISTER_B_DUAL_PIXEL, fps_timerB_override);
         EngDrvOutLV(FPS_REGISTER_CONFIRM_CHANGES, 1);
     }
     fps_timers_updated = 1;


features.h
@@ -11,7 +11,7 @@
// Tried it for a felt hundred hours
// TIMER_B has untraceable problems
// Using TIMER_A_ONLY causes banding / patterns
-#undef FEATURE_FPS_OVERRIDE
+// #undef FEATURE_FPS_OVERRIDE

/* see comments in lens.c */
#undef FEATURE_FOLLOW_FOCUS


internals.h
@@ -125,8 +125,11 @@
/** FIO_RenameFile works **/
#define CONFIG_FIO_RENAMEFILE_WORKS

-// FPS updates from evf state do not work atm on 70D
-// #define CONFIG_FPS_UPDATE_FROM_EVF_STATE
+// FPS override: change timers from EVF state */
+#define CONFIG_FPS_UPDATE_FROM_EVF_STATE

#define CONFIG_REC709




The cam doesn't lock-up anymore and doesn't show any funny effect on LCD when trying FPS override in LV. But the overriden FPS value shortly jumps to the default one every 2s. I think ML task does something with this interval. It also jumps shortly to default FPS for every navigation key pressed when in video tab. This is with no modules loaded. Here see how it looks:
https://youtu.be/ZnNLZ6sgp7Y


But you can nicely increase LCD visibility at night and MLV recording also works with the overriden FPS. However bitrate shown during recording is wrong, it shows just bitrate which would be true with default FPS. And also recording time is counting slower. Seems that the mlv_lite module doesn't get the right overriden FPS value for calculations.

Which function is called approx. every 2s when staying in menu? I must analyze it in details to see what causes the short glitch. Actually the first question shall be: does this value really change only for a short moment when ML is doing something or does ML realize it only after 2s from the moment when other piece of code changes it? As LV is showing permanent FPS override I hope for the first one.

During initial testing, the FPS was also getting back to default value after few first frames during recording. This seems to not happen anymore, I believe after changing the FPS update mode by  #define CONFIG_FPS_UPDATE_FROM_EVF_STATE in internals.h. But I haven't tested enough.

Here a build, so you can test as well. :) Feedback very welcome!

https://bitbucket.org/ArcziPL/magic-lantern/downloads/magiclantern-Nightly.2019Mar15.70D112_crop_rec_4k_mlv_lite_lossless_fps_override_experimental.zip

And for everyone, who gets "ISOless err xx" when trying to use DualISO, here a modified module with alternative adresses (just move it to ML/modules):
https://bitbucket.org/ArcziPL/magic-lantern/downloads/70d_dual_iso_alternative_adress.zip

As already mentioned above, enabling FPS override caused lossless compressor to break again. I had to remove one more resource to make it work again.

+    else if (is_camera("70D", "*"))
+    {
+        uint32_t resources[] = {
+            0x00000 | edmac_channel_to_index(edmac_write_chan),
+            0x10000 | edmac_channel_to_index(edmac_read_chan),
+            0x30001,    /* Read connection 1 (uncompressed input) */
+            0x2002d,    /* Write connection 45 (compressed output) */
+          //0x20016,    /* Write connection 22 (for WR2 - not used) */
+            0x50034,
+          //0x5002d,    /* workaround, TTL_Prepare stucks otherwise if called in LV */
+          //0x50010,    /* workaround, TTL_Prepare stucks otherwise if compiled with FEATURE_FPS_OVERRIDE defined */
+            0x90001,
+            0x230000,
+            0x160000,
+            0x260000,
+            0x260001,
+            0x260002,
+            0x260003,
+        };


Quote from: a1ex on March 15, 2019, 06:10:04 AM
Then, 70D also needs FRAME_SHUTTER_BLANKING_READ (i.e. the memory address of the shutter blanking register, as printed in adtg_gui). On some models, this address is a moving target, though, so we need to find another way to retrieve it.

On my cam it is different than the already present entry in crop_rec_4k_mlc_* which is commented out because of some reason.

// see "Malloc Information"
// #define FRAME_SHUTTER_BLANKING_ZOOM   (*(uint16_t*)0x40452180) // ADTG register 805f
// #define FRAME_SHUTTER_BLANKING_NOZOOM (*(uint16_t*)0x40452184) // ADTG register 8061

#define FRAME_SHUTTER_BLANKING_READ   (lv_dispsize > 1 ? FRAME_SHUTTER_BLANKING_NOZOOM : FRAME_SHUTTER_BLANKING_ZOOM)
#define FRAME_SHUTTER_BLANKING_WRITE  (lv_dispsize > 1 ? &FRAME_SHUTTER_BLANKING_ZOOM : &FRAME_SHUTTER_BLANKING_NOZOOM)


BTW: why does FRAME_SHUTTER_BLANKING_WRITE use swapped order of ZOOM and NOZOOM registers?! For other cams it looks same...

On my cam I see the following adresses:

805f: 0x404e6180
8061: 0x404e6184


How to see if the shutter_blanking is working or not at all? I've tried uncommenting and replacing with my two addresses but couldn't tell any difference...
M50.110 [main cam] | G7X III [pocket cam] | 70D.112 [gathers dust] | M.202 [gathers dust] | waiting for M5II

andy kh

5D Mark III - 70D

DeafEyeJedi

Great work @ArcziPL & @dfort! Also thanks @a1ex for pointers to get this 70D revived yet once again!
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

ArcziPL

[Here was some pointless whining but I removed it, as it was pointless. I'm on track, analyzing what happens and there will be no whining anymore, promise. :)]

I see that fps_get_current_x1000() is called several times per second in video LV and only in 1 out of 4 cases returns the expected (=override) value. Three others are the default FPS. Need to find out if it's Canon or ML, who keeps overriding the FPS back to default (or maybe just the readback is wrong?).

Next step was to keep FPS override turned off and call  fps_setup_timerA() + fps_setup_timerB() once from run_test(), followed by fps_get_current_x1000().

Result without CONFIG_FPS_UPDATE_FROM_EVF_STATE:
- 700D: after one frame the FPS is back to default
- 70D: same

Result with #define CONFIG_FPS_UPDATE_FROM_EVF_STATE:
- 700D: keeps FPS after one call
- 70D: LV and h264 recording stay overriden but fps_get_current_x1000() returns default FPS

Next step: tried to strip vsync_func() from everything but calling fps_update_timers_from_evfstate() but it didn't change anything.

Next step: try to reduce fps_task() to the absolute required minimum. This is still ongoing.
M50.110 [main cam] | G7X III [pocket cam] | 70D.112 [gathers dust] | M.202 [gathers dust] | waiting for M5II

zootrope

@ArcziPL thank you for your valuable work !

mvrck

Hi, everyone. I just got a 70D and I want to help out with testing. I tried two crop_rec_4k builds on it and while they work, the camera stops recording and throws an Err 70 after shooting for a while. Here are the builds I tried and the crash logs.

magiclantern-Nightly.2019Mar07.70D112_crop_rec_4k_mlv_lite_lossless:

ASSERT: FALSE
at ./ASIF/AsifState.c:448, ASIF:ff2bab88
lv:0 mode:3

ASIF stack: 191760 [191838-190838]
0xUNKNOWN  @ ef80:191830
0xUNKNOWN  @ 3db8c:191808
0x0003D884 @ ff116e6c:1917e0
0xUNKNOWN  @ 3d8b4:1917d0
0xUNKNOWN  @ 3d93c:1917b0
0x00001900 @ ff2bab84:191798
0x0044C46C @ 44c4ec:191760

Magic Lantern version : Nightly.2019Mar07.70D112
Mercurial changeset   : 02e5918a6ed5+ (crop_rec_4k_mlv_lite_snd)
Built on 2019-03-07 20:10:24 UTC by artur@Artur-VirtualBox.
Free Memory  : 215K + 2380K


This Mar07 build seems like the more stable of the two. I had only 'mlv_lite', 'mlv_snd' and 'sd_uhs' modules enabled, using the SD overclock, 14-bit lossless at fullres, 16:9, ISO100. The SD card is SanDisk Extreme Pro 95MB/s, 128GB.

magiclantern-crop_rec_4k_mlv_snd.2019Mar14.70D112:

ASSERT: FALSE
at ./ASIF/AsifState.c:448, ASIF:ff2bab88
lv:0 mode:3

ASIF stack: 191760 [191838-190838]
0xUNKNOWN  @ ef80:191830
0xUNKNOWN  @ 3db8c:191808
0x0003D884 @ ff116e6c:1917e0
0xUNKNOWN  @ 3d8b4:1917d0
0xUNKNOWN  @ 3d93c:1917b0
0x00001900 @ ff2bab84:191798
0x0044C478 @ 44c57c:191760

Magic Lantern version : crop_rec_4k_mlv_snd.2019Mar14.70D112
Mercurial changeset   : 32ac2f15f16c+ (crop_rec_4k_mlv_snd_experiments)
Built on 2019-03-14 22:49:12 UTC by [email protected].
Free Memory  : 300K + 1800K


ASSERT: FALSE
at ./ASIF/ASIF.c:383, raw_rec_task:ff1176b0
lv:0 mode:3

raw_rec_task stack: 1e3ed0 [1e3fe0-1e2fe0]
0x00C27538 @ c2d740:1e3f50
0xUNKNOWN  @ c2756c:1e3f40
0x00C3086C @ c309a8:1e3f38
0xFF11758C @ c308e0:1e3f20
0x00001900 @ ff1176ac:1e3f08
0x0044C478 @ 44c57c:1e3ed0

Magic Lantern version : crop_rec_4k_mlv_snd.2019Mar14.70D112
Mercurial changeset   : 32ac2f15f16c+ (crop_rec_4k_mlv_snd_experiments)
Built on 2019-03-14 22:49:12 UTC by [email protected].
Free Memory  : 300K + 1801K


The Mar14 build didn't have the 'sd_uhs' module, so I lowered the resolution to get >40MB/s writes (everything else was the same), but alas, it didn't work and I still got an Err 70 after even less recording time, than the other build.

EDIT: Now the Mar07 build started giving me Err 70 after just seconds of recording, even in 11-8 bit and 1:2.35 ratio.. I was worried that my new (well, second hand) camera had issues, but taking pictures and shooting h.264 works perfectly fine.

If there's something I could try out, let me know.


mvrck

Quote from: Walter Schulz on March 28, 2019, 04:13:07 PM
You know about Canon's service advisory about Err70 on 70D?

Now that you mention it, I think I've read something about that, but I've obviously forgotten about it since. My camera's serial number begins with 24, though. The Err 70 only appears when I record RAW video and I don't even have to turn off the camera or reinsert the battery. After ML's finished writing the crash log, I simply half-press the shutter and the error clears, as if it never happened. This is why I suspect it has something to do with ML.

a1ex

ERR70 can be triggered by over 1000 different conditions. Some of them are caused by ML, others are hardware issues.

This one looks like something related to sound recording. Is the error still there with the regular nightly build for 70D from the download page? If the error is not present with the regular build, it must be something in the experimental builds.

To narrow down, is the error present with...
- ML defaults (Prefs -> Card settings) and H.264 recording?
- ML defaults and only mlv_rec (without sound)?
- ML defaults and only mlv_lite (without sound)?
- ML defaults and only mlv_rec + mlv_snd?
- ML defaults and only mlv_lite + mlv_snd? nevermind

Unlikely to help, but you could also try restoring Canon settings.

mvrck

Quote from: a1ex on March 28, 2019, 04:45:33 PM
ERR70 can be triggered by over 1000 different conditions. Some of them are caused by ML, others are hardware issues.

This one looks like something related to sound recording. Is the error still there with the regular nightly build for 70D from the download page? If the error is not present with the regular build, it must be something in the experimental builds.

To narrow down, is the error present with...
- ML defaults (Prefs -> Card settings) and H.264 recording?
- ML defaults and only mlv_rec (without sound)?
- ML defaults and only mlv_lite (without sound)?
- ML defaults and only mlv_rec + mlv_snd?
- ML defaults and only mlv_lite + mlv_snd?

Unlikely to help, but you could also try restoring Canon settings.

Ok, so with the lastest nightly (magiclantern-Nightly.2018Dec24.70D112), this is what happens:

- ML defaults and only mlv_lite + mlv_snd - module clash error - no go
- ML defaults and only mlv_rec + mlv_snd - records for a few seconds and then Err70
- ML defaults and only mlv_rec (without sound) - I recorded 17 mins of raw footage, no problem (battery drained and I had to stop)
- ML defaults and only mlv_lite (without sound) - recorded raw footage, until my 128GB card filled up - a little over 51 mins - no problem

Of course, this nightly not having lossless or sd overclocking, I used something like 1600x600 (1:2.67), if that matters at all. So, it does indeed look like the sound module is causing the issue. Also, I should mention, that when I tested the Mar07 and Mar14 builds, I didn't use the default settings - I turned off small hacks, allowed screen mirroring and used LV Digic peaking with sharpening (that's all, I think). I'll now test the Mar07 and Mar14 builds again, but with the default settings, with and without sound, and report back.

a1ex

Alright. I assume the sound recording feature works on 70D, otherwise it would have been reported many times.

Not sure what to recommend - maybe checking the same ML card in two different 70Ds, both reset to Canon defaults and running at exactly the same settings, to exclude a hardware issue?

Or, I could try to debug mlv_snd, but... remote debugging is going to be time-consuming for both of us. I might be able to do that on April 7/8 (unless unexpected stuff happens meanwhile), so please remind me then if you can't find what's going on.

mvrck

I don't have another 70D to test on, but I'll continue testing the different builds with different settings and when I have something, I'll report back.

andy kh

I hv been shooting 14 bit lossless mlv lite with sound and hv no issues so far
5D Mark III - 70D

ArcziPL

Quote from: mvrck on March 28, 2019, 06:25:13 PM
- ML defaults and only mlv_lite + mlv_snd - module clash error - no go
- ML defaults and only mlv_rec + mlv_snd - records for a few seconds and then Err70
- ML defaults and only mlv_rec (without sound) - I recorded 17 mins of raw footage, no problem (battery drained and I had to stop)
- ML defaults and only mlv_lite (without sound) - recorded raw footage, until my 128GB card filled up - a little over 51 mins - no problem
Hi mvrck, thank you for extensive testing! 1h of recording without an error is a pretty good indicator that there should be no problem with the hardware of your cam (but still not a real proof).

Regarding the sound itself it's interesting, as Mar07 and Mar14 builds are based on two different branches (crop_rec_4k_mlv_lite_snd and crop_rec_4k_mlv_snd), which implement sound support in different ways. And they both crash for you...

I have four ideas:
1. There should be some audio settings in Canon menu as well -> auto gain optimizer and wind filter, if I recall correctly. Try to play around with them and see if it has any effect on the crashes.
2. Use the camera without magic lantern, record normal h264 with sound (standard, official feature of this camera). Does it crash then?
3. Use the Mar07 or Mar14 builds with sd_uhs+lossless and disable sound by deactivating mlv_snd. I wonder if these builds also will stop crashing...
4. Restore camera factory settings over Canon menu.

Regarding the other camera settings: I used only 1080p/25fps setting from Canon menu, resulting in 1832x1024 RAW image size. Small hacks: in last year I used the default setting, in last days disabled. Screen mirroring: default. DIGIC peaking: sharpening.
M50.110 [main cam] | G7X III [pocket cam] | 70D.112 [gathers dust] | M.202 [gathers dust] | waiting for M5II

mvrck

OK, here are the results from my testing.

Mar07 Build

mlv_lite
1776x1000, 14-bit lossless, 16:9
Preview: Realtime
40 min. - OK
--------------------------------
mlv_rec
1792x716, 10bpp, 2.50:1
Global Draw: Allow
40 min. - OK
--------------------------------
mlv_lite + sd_uhs
1832x1024, 14-bit lossless, 16:9
Preview: Realtime
40 min. - OK
--------------------------------
mlv_rec + sd_uhs
1824x1026, 10bpp, 16:9
Global Draw: Allow
40 min. - OK
--------------------------------
mlv_rec + mlv_snd
1792x716, 10bpp, 2.50:1
Global Draw: Allow
Err70, after a few seconds
--------------------------------



Mar14 Build

mlv_lite
1776x1000, 14-bit lossless, 16:9
Preview: Realtime
40 min. - OK
--------------------------------
mlv_rec
1792x716, 10bpp, 2.50:1
Global Draw: Allow
40 min. - OK
--------------------------------
mlv_rec + mlv_snd
1792x716, 10bpp, 2.50:1
Global Draw: Allow
Err70, after a few seconds
--------------------------------

In all the tests I used ISO100, 24 FPS. A run the first test for 40 minutes and decided to run all other tests for as long, not just for consistency, but also to test the camera's stability. All tests were done back to back, using two batteries - one being used, while the other was being charged. The camera was pretty warm throughout, but didn't pass 58*C. According to Canon, Err70 occurs with prolonged use and supposed heat build-up, so I had to test for that. I don't know anything that heats up cameras and drains batteries quite like shooting RAW video, so I guess my 70D passed the test. Anyway, the result is that the mlv_snd module always produces Err70, when activated, unfortunately.

@ArcziPL
1. I tried setting the audio to manual and turning on and off the wind filter and attenuator, but it didn't help
2. There's absolutely no problem with the camera taking pics and shooting h.264 with or without ML loaded
3. I think my test results answer that one :)
4. Tried that, too - doesn't work

andy kh

http://www.youtube.com/watch?v=KtYcu_YeApI&feature=youtu.be
here is a video showing of my test that mlv lite(lossless 14 bit) with sound works but get some error msg on screen when i record mlv with sound
i hope someone wil understand better by watching the video
5D Mark III - 70D