12-bit (and 10-bit) RAW video development discussion

Started by d, May 22, 2013, 10:58:34 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

dfort

Quote from: IDA_ML on January 03, 2018, 10:12:31 PM
Well, there must be some difference, otherwise, why would you post two absolutely identical builds on two subsequent days?  I tested both builds extensively and provided detailed feedback (see posts 1390 and 1454 for the Dec. 5 and  Dec. 11 builds, respectively and compare them with post 1465 describing the behavior of the Dec. 12-th build).   If you do not trust the feedback information that I provided, you could test these builds by yourself with your own 7D.  There must be some explanation why the two builds behave so differently.

I added links on your references to previous posts because it took a while to look them up.

If you look at the autoexec.bin files in a text editor you will see that the builds aren't exactly identical but the changes that were made between Dec. 11 and Dec. 12 shouldn't have changed anything on the 7D. I did do some tests on the two builds and didn't see any difference but as long as I was updating some of the other builds I updated all of them. I haven't found a way to sort the downloads page in Bitbucket and wanted to make sure all the builds were next to each other.

One thing that might be causing some issues is that I merged in the edmac module on Dec. 11. I posted a regression test before the merge (Dec. 10) and after which should be that Dec. 11 build that is working for you. Note that sometimes I'll post more than one build in a day so if you could, please open the autoexec.bin file on that build that is working so well for you and post it here so we can track down the changeset.

src/edmac-memcpy.c
    resLock = CreateResLockEntry(resIds, 4);
   
    ASSERT(resLock);

    /* just to make sure we have this stub */
    static int AbortEDmac_check __attribute__((used)) = &AbortEDmac;
}

INIT_FUNC("edmac_memcpy", edmac_memcpy_init);


Danne

I used a build from december 6th that seemed to work(it´s named dec 5th, raw_video_10bit_12bit.2017Dec05.7D203.zip):
http://www.magiclantern.fm/forum/index.php?topic=19336.msg194188#msg194188

I think this is the version still on my computer, opened up the autoexe.bin:
Magic Lantern Nightly.2017Dec05.7D203
Camera   : 7D
Firmware : 203
Changeset: 870cedc16e2d+8f8e391db888+ (raw_video_10bit_12bit_allocate-raw-lv-buffer)
Built on : 2017-12-06 04:13:07 by rosiefort@RosieFoComputer

diff -r 870cedc16e2d src/edmac-memcpy.c
--- a/src/edmac-memcpy.c Thu Aug 17 12:07:00 2017 +0300
+++ b/src/edmac-memcpy.c Tue Dec 05 20:13:07 2017 -0800
@@ -341,6 +341,8 @@
uint32_t raw_write_chan = 0x4;  /* 0x12 gives corrupted frames on 1.2.3, http://www.magiclantern.fm/forum/index.php?topic=10443 */
#elif defined(EVF_STATE)
uint32_t raw_write_chan = 0x12; /* 60D and newer, including all DIGIC V */
+#elif defined(LV_STATE)
+uint32_t raw_write_chan = 0x10; /* older DIGIC IV LVState cameras */
#endif

static void edmac_slurp_complete_cbr (void* ctx)
diff -r 870cedc16e2d src/raw.c
--- a/src/raw.c Thu Aug 17 12:07:00 2017 +0300
+++ b/src/raw.c Tue Dec 05 20:13:07 2017 -0800
@@ -133,10 +133,45 @@
#define DEFAULT_RAW_BUFFER MEM(0x76d6c + 0x2C)
#endif

-#else
+#ifdef CONFIG_1100D
+#define RAW_LV_BUFFER_ALLOC_SIZE (3906*968)
+#endif
+
+#ifdef CONFIG_7D
+#define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0x1000)
+#endif
+
+#ifdef CONFIG_5D2
+#define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0x1000)
+#endif
+
+#ifdef CONFIG_50D
+#define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0x1000)
+#endif
+
+#ifdef CONFIG_550D
+#define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0x1000)
+#endif

-/* with Canon lv_save_raw, just read it from EDMAC */
-#define DEFAULT_RAW_BUFFER shamem_read(RAW_LV_EDMAC)
+#else // "Traditional" RAW LV buffer detection
+
+/**
+ * LiveView raw buffer address
+ * To find it, call("lv_save_raw") and look for an EDMAC channel that becomes active (Debug menu)
+ **/
+
+#if defined(CONFIG_5D2) || defined(CONFIG_50D)
+#define RAW_LV_EDMAC 0xC0F04508
+#endif
+
+#if defined(CONFIG_500D) || defined(CONFIG_550D) || defined(CONFIG_7D)
+#define RAW_LV_EDMAC 0xC0F26008
+#endif
+
+#if defined(CONFIG_DIGIC_V) || defined(CONFIG_600D) || defined(CONFIG_60D)
+/* probably all new cameras use this address */
+#define RAW_LV_EDMAC 0xC0F26208
+#endif

#endif

@@ -399,6 +434,23 @@
extern void reverse_bytes_order(char* buf, int count);

#ifdef CONFIG_RAW_LIVEVIEW
+
+#if defined(CONFIG_ALLOCATE_RAW_LV_BUFFER)
+static void* raw_allocated_lv_buffer = 0;
+#endif
+
+static void* raw_get_default_lv_buffer()
+{
+#if !defined(CONFIG_EDMAC_RAW_SLURP)
+    return (void*) shamem_read(RAW_LV_EDMAC);
+#elif defined(DEFAULT_RAW_BUFFER)
+    return (void*) DEFAULT_RAW_BUFFER;
+#elif defined(CONFIG_ALLOCATE_RAW_LV_BUFFER)
+    return raw_allocated_lv_buffer;
+#else
+    #error DEFAULT_RAW_BUFFER not configured.
+#endif
+}
/* returns 1 on success */
static int raw_lv_get_resolution(int* width, int* height)
{
@@ -521,7 +573,7 @@
         }
         #endif

-        raw_info.buffer = (void*) DEFAULT_RAW_BUFFER;
+        raw_info.buffer = raw_get_default_lv_buffer();
         
         if (!raw_info.buffer)
         {
@@ -1581,7 +1633,7 @@
void FAST raw_lv_vsync()
{
     /* where should we save the raw data? */
-    void* buf = redirected_raw_buffer ? redirected_raw_buffer : (void*) DEFAULT_RAW_BUFFER;
+    void* buf = redirected_raw_buffer ? redirected_raw_buffer : raw_get_default_lv_buffer();
     
     if (buf && lv_raw_enabled)
     {
@@ -1851,6 +1903,14 @@
#ifndef CONFIG_EDMAC_RAW_SLURP
     call("lv_save_raw", 1);
#endif
+
+#ifdef CONFIG_ALLOCATE_RAW_LV_BUFFER
+    uint32_t old = cli();
+    if(!raw_allocated_lv_buffer) {
+        raw_allocated_lv_buffer = fio_malloc(RAW_LV_BUFFER_ALLOC_SIZE);
+    }
+    sei(old);
+#endif
}

static void raw_lv_disable()
@@ -1860,6 +1920,15 @@
#ifndef CONFIG_EDMAC_RAW_SLURP
     call("lv_save_raw", 0);
#endif
+
+#ifdef CONFIG_ALLOCATE_RAW_LV_BUFFER
+    uint32_t old = cli();
+    if(raw_allocated_lv_buffer) {
+        free(raw_allocated_lv_buffer);
+        raw_allocated_lv_buffer = 0;
+    }
+    sei(old);
+#endif
}

int raw_lv_is_enabled()
diff -r 870cedc16e2d platform/7D.203/consts.h
--- a/platform/7D.203/consts.h Thu Aug 17 12:07:00 2017 +0300
+++ b/platform/7D.203/consts.h Tue Dec 05 20:13:07 2017 -0800
@@ -262,6 +262,7 @@
// see "Malloc Information"
#define MALLOC_STRUCT 0x249e4
#define MALLOC_FREE_MEMORY (MEM(MALLOC_STRUCT + 8) - MEM(MALLOC_STRUCT + 0x1C)) // "Total Size" - "Allocated Size"
+#define SRM_BUFFER_SIZE 0x1F80000   /* print it from srm_malloc_cbr */

//~ max volume supported for beeps
#define ASIF_MAX_VOL 5
diff -r 870cedc16e2d platform/7D.203/internals.h
--- a/platform/7D.203/internals.h Thu Aug 17 12:07:00 2017 +0300
+++ b/platform/7D.203/internals.h Tue Dec 05 20:13:07 2017 -0800
@@ -129,3 +129,7 @@

/** Use joystick for one-finger menu navigation */
#define CONFIG_JOY_CENTER_ACTIONS
+
+/** this method bypasses Canon's lv_save_raw and slurps the raw data directly from connection #0 */
+#define CONFIG_EDMAC_RAW_SLURP
+#define CONFIG_ALLOCATE_RAW_LV_BUFFER


How do one search for a changeset in source tree?
Changeset: 870cedc16e2d+8f8e391db888+

All I can find is your link to an early build in this post but it´s been removed:
http://www.magiclantern.fm/forum/index.php?topic=19336.msg194178#msg194178

dfort

Interesting, that was from a different branch. The first thing I tried was to see if the allocate raw lv buffer experiment that @nanomad did on the 1100D could be ported over to other Digic 4 cameras. I jumped to another branch because the point of all this is to get these cameras integrated into the experimental branches that are built on the Jenkins server.

Quote from: Danne on January 04, 2018, 06:17:08 AM
How do one search for a changeset in source tree?
Changeset: 870cedc16e2d+8f8e391db888+

All I can find is your link to an early build in this post but it´s been removed:
http://www.magiclantern.fm/forum/index.php?topic=19336.msg194178#msg194178

You can find it either on the Bitbucket website:



Or in a clone of my repository using this command:

hg update 870cedc16e2d+8f8e391db888

Danne


IDA_ML

Quote from: dfort on January 04, 2018, 05:04:13 AM
please open the autoexec.bin file on that build that is working so well for you and post it here so we can track down the changeset.

I have a better idea, Dfort.  I have packed your Dec. 11-th build directly from my camera into a .RAR archive that you can download in the next 7 days from here:

https://we.tl/BkF9sH3Ymk

In this way, you do not only have the autoexec.bin file but also the entire build, including the config file, so you can see what camera settings I have been using.  I believe, I have just added a raw_tweak module to the Modules directory to enable in-camera palyback of the recorded clips.  If you please upload the build as it is to your 7D you will be able to precisely reproduce all the tests that I made and provided feedback on.

After several more tests, I have to admit that this Dec. 11-th build is not very stable either but it WORKS!  When I use the normal uncropped modes (RAW-video (MLV) and RAW-video, 1728x972 resolution @24 fps, 10/12 bit), the first recording after camera has been switched on is perfectly OK.  Subsequent recordings sometimes work out fine, sometimes get shaky.  If this happens, I have to turn camera off and on again to make it record properly, without earthquake shaking.  In the 5x-magnification mode there is no earthquake shaking and I can record clips even at the maximum 2496x1198 resolution with sound but the frozen screen during recording makes the usage of this fantastic mode very limited.

I believe, the first 10/12 bit recording after camera is turned on is a very good starting point to identify the condition at which earthquake shaking does not occur.

I hope this helps and keep my thumbs pressed that you succeed!

dfort

Thanks @IDA_ML

This is interesting, the "Miracle Build" was compiled on the Windows 7 system that I used at work--using the Cygwin environment. It shouldn't make any difference if ML is compiled on Windows, Linux or Mac but maybe? It would be great if you could test it against the Dec. 11 Mac build I posted yesterday.

@Danne -- check out the branch, it isn't the allocate-raw-lv-buffer-wip branch. Backing out the changes since Dec. 11 will only remove the raw_twk module. The other changes were only on the 1100D and 5D2.

Magic Lantern Nightly.2017Dec11.7D203
Changeset: 7a58a90ecbb4+fee1ee2bf3b3+ (raw_video_10bit_12bit_LVState-wip) tip
Camera   : 7D
Firmware : 203
Built on : 2017-12-11 17:22:07 by dfort@QANTAS

diff -r 7a58a90ecbb4 src/edmac-memcpy.c
--- a/src/edmac-memcpy.c Sun Dec 10 08:40:46 2017 -0800
+++ b/src/edmac-memcpy.c Mon Dec 11 09:22:07 2017 -0800
@@ -81,6 +81,9 @@
     resLock = CreateResLockEntry(resIds, 4);
     
     ASSERT(resLock);
+
+    /* just to make sure we have this stub */
+    static int AbortEDmac_check __attribute__((used)) = &AbortEDmac;
}

INIT_FUNC("edmac_memcpy", edmac_memcpy_init);
Changeset: 7a58a90ecbb4+fee1ee2bf3b3+ (raw_video_10bit_12bit_LVState-wip) tip
Built on : 2017-12-11 17:22:07 by dfort@QANTAS





diff -r 7a58a90ecbb4 src/edmac-memcpy.c
--- a/src/edmac-memcpy.c Sun Dec 10 08:40:46 2017 -0800
+++ b/src/edmac-memcpy.c Mon Dec 11 09:22:08 2017 -0800
@@ -81,6 +81,9 @@
     resLock = CreateResLockEntry(resIds, 4);
     
     ASSERT(resLock);
+
+    /* just to make sure we have this stub */
+    static int AbortEDmac_check __attribute__((used)) = &AbortEDmac;
}

INIT_FUNC("edmac_memcpy", edmac_memcpy_init);


Interesting that the changes that were not committed are showing up twice. I've never seen that before.

IDA_ML

Quote from: dfort on January 04, 2018, 05:13:20 PM
It would be great if you could test it against the Dec. 11 Mac build I posted yesterday.

LOL, Dfort, things seem to get quite messy here.  I don't know which build you mean.  I do not see a "Dec. 11 Mac build" in your download area.  Could you please send me a download link and I will test it for you.

By the way, I might be able to find your very first build with the RAW_Slurp issue resolved, that you posted, (I believe, this was the Dec. 5-th or 6-th build).  I remember, it was quite buggy and there was no in-camera playback but in the uncropped RAW-video modes, it seemed to provide 10/12 bit clips without earthquake shaking.  I you want that build as a starting point, please let me know and I will look for it on my home PC.

One more suggestion.  As I reported, with the Dec. 11-th Miracle build, the first 10/12-bit recording after camera is turned on, works fine - no shaking.  With the second and following ones there is no guarantee that you will not get a shaky clip and you never know which one that clip will be until you play it.  Maybe you could implement some kind of an automatic routine that simulates the camera turn-on condition right after the first clip is recorded.  In this way, the camera will always think that it has just been turned on and will record the next clip without shaking.  Then the routine is run again after the second clip and then again and again until all clips are properly recorded.  I know, this is not a very elegant solution but if it works, why not?  How about that?

IDA_ML

Dfort,

I have some very good news for you!  I think, I found out what is causing the earthquake shaking in the 7D videos.  It is not your builds, it is the RAW TWEAK MODULE that we added to enable in-camera playback!

As I said, I found your December 6-th build on my computer and started testing it again.  I was able to record many clips one after the other with both: the RAW-video (MLV) and the RAW-video modules in the normal uncropped mode at 24fps and 1728x972 and 1736x976 resolutions, respectively.  I downloaded them to the computer and palyed them back after conversion to H.264 files.  And guess what.  There was not a single clip with the earthquake shaking!  All clips were perfectly OK without a single corrupt frame in them.  In the RAW-video (MLV) mode sound also works synchronously.

Then I decided to add a Raw-tweak module to allow in-camera playback and view the clips right after they have been recorded.  And voila, just the first clip after camera is turned on is OK.  All the ones that follow are shaky!  This is clearly seen during in-camera playback.  And I also confirmed the shakyness in the computer.  Then I disabled the RAW-tweak module again and took several more clips in the above modes.  The shakyness was gone!

So, my conclusion is that not your modules but the RAW-tweak module needs a fix. 

I have now uploaded for your reference that Dec. 6-th build as I downloaded it originally a month ago (without the RAW-tweak module):

https://we.tl/swGMxT851M

If you could please repeat my tests with this build on your 7D, I am sure, you will be very pleasantly surprised and will know how to proceed. So, don't dispare but keep up your excellent work!

12georgiadis

I can confirm what IDA_ML is saying about crashing issue due to raw playback, both on the 7D and 5dmk3. And it's not related to one build. I stopped to use it because I had to reset the camera so many time. That's why h264 proxy playback is a god function to playback clips after recording on any camera. It's stable on 5Dmk3. I hope it can be generalized on others cameras


Envoyé de mon iPhone en utilisant Tapatalk

dariSSight

Happy New Year To My Fellow Magic Lantern Enthusiasts,

I just read the possible corrections to the builds I've been testing but they give me shake Choppy video, but I will try it without RAW TWK module.

@dfort @reddeercity
When I make a build on Mac is it correct that I should open up Sourcetree, double click on raw_video_10bit_12bit_LVState-wip in Clone, then open terminal paste

cd Magic-LanternCloneRepository/platform/5D2.212
make zip
cp *.zip ~/Desktop
make clean

Take zip from desktop, install it on cf card, Also when we make edits do we edit the raw.c in src folder? And how do we know what to edit?

I know these question are all over the place but they will help me figure out how to assist in the builds. Thanks again
Canon 5D Mark II

dariSSight

These links (may take about 30min to upload) are to video with choppy video, also it is still choppy outcome even with raw_twk.mo turned off

https://www.dropbox.com/s/e5717umzd2hhb0d/CropM04-1943.mov?dl=0
https://www.dropbox.com/s/6hh783vws66befm/Non-CropM04-1942.mov?dl=0
Canon 5D Mark II

IDA_ML

To the developers familiar with the RAW-tweak module

This module urgently needs troubleshooting and fixing, otherwise it undermines the developers' efforts to port crop_4k RAW video to various cameras !  

As far as I understand, the RAW-tweak module is used to playback 10 and 12-bit uncompressed MLV clips in the camera.  I does this job very well and is quite useful to quickly review the clips right after they have been recorded.  If it is not loaded or disabled, a black screen occurs when trying to playback a 10/12-bit clip.  Unfortunately, when the module is available in the Modules directory and activated, it seems to interfere with other RAW video recording features, in particular with the MLV-lite module, and causes a lot of trouble.  That is why, in most cases, it has to be disabled to get the work done.

Below, please find a brief description on what happens when the RAW-tweak module is active on some of the cameras:

The EOS 7D with the Dec. 6-th 2017 build by Dfort:
================================

In the normal uncropped modes (RAW-video (MLV) and RAW-video, 1728x972 resolution @24 fps, 10/12 bit), the first recording after camera has been switched on is perfectly OK.  Subsequent recordings get shaky and this can be clearly observed during in-camera playback.  If this happens, the camera has to be turned off and on again to make it record properly, without earthquake shaking for one more clip.  Once the module is disabled, all subsequent clips in the above modes get perfectly recorded and there are no glitches, corrupt frames or shaking.  No camera turning-off is required.  These error free clips can also be viewed in the camera after the module is activated again to verify that there is no shaking. 

The EOS 100D/SL1, Dec. 19-th Experimental build
===============================

The RAW-tweak module does not work in any of the RAW-video modes.  When the record button is pressed, the "Threads failed to start" message appears and the screen turns black.  A red dot and a "Starting" message appears next to the RAW-video mode selected but recording never starts.  When the module is disabled, recording works normally but when it is enabled again to playback the recorded clips, a black screen occurs.  When now halfshutter is pressed the red LED starts blinking but the screen remains black.  The red LED does not stop blinking even after the camera is turned off.  The only way out of this state is a battery pull.  The RAW-tweak module has to be disabled for proper camera operation.

The EOS 5DMkIII (several builds with the RAW-tweak module included)
============================================

See the brief explanation by 12georgiadis in his post #1559 above.

-------------------------------------------------------------------------------

I hope, the above behavior can be confirmed also by other users and the RAW-tweak module will receive a fix to allow further work on the latest developments.



IDA_ML

Are 12georgiadis and I the only people having trouble with the RAW-tweak module?  Please report on your experience with it.

Kharak

5D3 123

I dont have any issues with RAW_twk.mo and recording. Not with MLV_Lite or MLV


I had some random issues at times not being able to play MLV's in camera except for the last shot. But I believe I fixed it by removing some IDX files.
once you go raw you never go back

IDA_ML

What about owners of of other camera models (EOS M and 700D)?  Does the RAW-tweak module cause problems with the latest experimental builds with crop-4K recording on your cameras?  How about the cameras working with 10/12-bit recording?

dfort

raw_twk is causing problems on the EOSM possibly because it has maxed out on the number of threads it can handle.

This might also explain why things were working better on my older 7D builds before I added the raw_twk module.

As far as the future of the raw_twk module, I think that the plan might be to eventually incorporate something more efficient in mlv_play to playback lossless compressed files. Then again if we can get H.264 proxy working you will be able to playback the H.264 file with audio in camera.

Off topic: @IDA_ML -- There has been lots of work recently to get the focus pixel map files working for 8...12-bit lossless compressed files in MLVFS. Most of the testing was done on EOSM and 700D but it could really use a thorough test from an experienced 100D user.  ;)

dfort

I took another look at a video recorded on the 7D in 10bit:

Block: RAWI
...
    Res:  2520x1192
    raw_info:
...
      height           1224
      width            2520
...
      bits_per_pixel   10


The image size and raw buffer check out as valid:

In [1]: 2520*14//8*1224 % 16
Out[1]: 0

In [2]: 2520*14//8*1192 % 16
Out[2]: 0


Raw buffer height (1224) - skip_top (26) = 1198 so why is the Image height only 1192?

In [3]: 2520*14//8*1198 % 16
Out[3]: 12


Not valid. Ok--this makes sense.

But it looks like there is some doubt these are the right skip settings:

raw.c from the raw_video_10bit_12bit and unified branches:
        #ifdef CONFIG_7D
        #warning FIXME: are these values correct for 720p and crop modes?
        skip_top    = 26;
        skip_left   = zoom ? 0 : 256;
        #endif


So it looks like we should run raw_diag and shoot some simple silent DNG's on the 7D and figure out where the out of bounds area is located on the various video modes, right?

IDA_ML

Dfort,

I have a strategic question on the 7D development to you.  You said that the 10/12 bit incompressed RAW video development is a tough nut to crack and I fully agree with you keeping in mind how much time and efforts you invested in this development.  My question to you is: 

Do we really need 10/12 bit uncompressed? 

Since October last year, I have been shooting 8...11 bits and 12 bits losslessly compressed video with sound (continuous recording at 24fps) on the 100D and could not be happier.  Video quality is fantastic and files are finally reduced in size to reasonable levels.  Since then, I never felt the necessity to film at 10, 12 or 14 bits uncompressed.  So, to continue my question on the 7D let's consider the hypothesis that the 10/12 bit incompressed is left alone for a while and porting 4K_crop_recording is proceeded with.  Would that be possible and if yes wouldn't that be easier and with better chances for success than 10/12 bit incompressed?  If the answer to that question is yes, then, keeping in mind the fast write speed of the 7D, we would have continuous 8...11 bit or even 12-bit LL recording WITH SOUND in the 2520x1200 resolution!  Imagine for how many people such video would be a dream come through !!!

Let us know what you think.

dfort

My understanding is that we need to get 10/12 bit uncompressed before attempting to compress it. Maybe we could skip 10/12 bit and go to 14 bit compressed but then everyone will still want 10/12 bit compressed.

I think the way we dealt with the 100D "hiccup" issue might bring us a step closer to figuring out how to resolve the "earthquake" issue in 10/12 bit on the 7D. If nothing else, those skip values should be verified. This is something you can do with the raw_dia module. No coding necessary. It is available on the bottom of the modules downloads page.

IDA_ML

Dfort,

Your Dec. 06-th, 2017 build with the raw_tweak module disabled works perfectly OK with 10/12 bits uncompressed RAW-video in the normal uncropped mode on the 7D.  No "earthquake shaking" is observed!  For stable 10/12-bit operation at the 5x-magnification mode, I still use the Dec. 1, 2016 build - the "haunting" one.  Once you get the Preview working properly, (by switching preview modes back and forth), this 5x-mode also provides excellent and very stable results with sound even at the highest 2496x1198 resolution.  I love filming with these two builds!  May be, starting from them is a good idea ???

I have now downloaded the raw_diag.mo but I don't know how and what to test and expect.  I don't know how to "save the RAW buffer" either.  If you give me detailed instructions on how to test, at what camera settings and what to expect, I can give it a try.  I cannot perform tests if I don't understand what they are doing.

dfort

A good place to start is reading the CMOS/ADTG/Digic register investigation on ISO topic.

Things to do:


  • Shoot simple silent DNG's at various movie mode settings and examine them with dcraw, exiftool, etc. Check out what the full raw buffer looks like by running "dcraw -E -4 [input.dng] and measure the out of bounds areas in a graphics editing program like Photoshop or Gimp.
  • Once you figure out the size of the out of bounds areas they should match the skip values.

raw_diag does several tests but what we're looking for is being able to save an image that looks something like this:



Notice how that blue line is showing the active area defined by ML.

dfort

Looks like @dariSSight found something that works better on the 5D2. I had this before but it didn't make sense that only the 5D2 would be different but hey--so much of this stuff doesn't make sense to me!

src/raw.c
#ifdef CONFIG_5D2
- #define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0x1000)
+ #define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0xF000)
#endif


Don't have a 5D2 to test so I'll just follow his lead. Made the change and posted a test build on my downloads page.

masc

@dfort: I tried it with my 5D2:
mlv_rec + mlv_snd: 1856x1044 10bit/12bit flickers pink. When enabling fps override @20fps all is fine. @23.976 it flickers again.
5D3.113 | EOSM.202

dariSSight

These are the 2 Builds it gives me when I use Terminal
https://www.dropbox.com/sh/acqkc6zebq7ryq6/AAB7AqgJGoKwJQECPi6yrifya?dl=0

so should I keep using -
cd Magic-LanternCloneRepository/platform/5D2.212
make zip
cp *.zip ~/Desktop
make clean

I do have two Directory I think 1.magic-lantern & 2.Magic-LanternCloneRepository, so should I delete 1.magic-lantern Directory
Canon 5D Mark II

dfort

Both of those builds are almost identical. The only difference being the date you saved and compiled them. It is easy to figure out if you open autoexec.bin in a text editor:

Magic Lantern Nightly.2018Jan16.5D2212
Camera   : 5D2
Firmware : 212
Changeset: 857ed765edf8+ (raw_video_10bit_12bit_LVState-wip)
Built on : 2018-01-16 10:17:43 by dariSSightEntertainment@dariSSiinneyMBP

diff -r 857ed765edf8 src/raw.c
--- a/src/raw.c Fri Dec 22 19:08:35 2017 -0800
+++ b/src/raw.c Tue Jan 16 05:17:43 2018 -0500
@@ -142,7 +142,7 @@
#endif

#ifdef CONFIG_5D2
-#define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0x1000)
+#define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0xF000)
#endif

#ifdef CONFIG_50D


Magic Lantern Nightly.2018Jan27.5D2212
Camera   : 5D2
Firmware : 212
Changeset: 857ed765edf8+ (raw_video_10bit_12bit_LVState-wip)
Built on : 2018-01-27 07:02:58 by dariSSightEntertainment@dariSSiinneyMBP

diff -r 857ed765edf8 src/raw.c
--- a/src/raw.c Fri Dec 22 19:08:35 2017 -0800
+++ b/src/raw.c Sat Jan 27 02:02:58 2018 -0500
@@ -142,7 +142,7 @@
#endif

#ifdef CONFIG_5D2
-#define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0x1000)
+#define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0xF000)
#endif

#ifdef CONFIG_50D


So you cloned my repository twice? No big deal but of course you don't really need to do that. You can delete one or the other, it doesn't matter. In fact you can rename one of them magic-lantern-dfort (my forum name) or magic-lantern-daniel_fort (my Bitbucket name) it doesn't really matter. What is important is that you know which repository you're working from. You may want to clone the main (hudson) repository so you also have access to the latest "official" source code. I tend to update my repository quite often and merge in the latest changes from the hudson repository.

At some point if you want to submit a pull request so your changes get into the main repository you should fork the hudson repository. There's lots of tips on the Internet for using hg (Mercurial) or the gui front end, SourceTree.

In any case, what you are doing looks fine. At least I don't see any problems from here.