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

[dfort]

At the beginning of lv_raw_dump on the M there is a call made to a function in ram (branch instruction)...We can use RAM_OFFSET to find the location of that function in rom...

Code: [Select]

#define RAM_OFFSET 0xFFA69590

This leads to this function in ROM:

Code: [Select]

FFA7A184: ldr r0, [pc, #808] ; 0xffa7a4b4: pointer to 0x404e4
FFA7A188: ldr r0, [r0, #68] ; 0x44
FFA7A18C: bx lr


Let's see if I understand. This means that the function call should be specifying an address of 0x10BF4 (FFA7A184 - RAM_OFFSET) but there is no such address in the the EOSM disassembly that I've got. There was enough of a hint in that function in the EOSM disassembly for me to look up that same function in the 700D and I came up with 0x25B0C + 0x3C. I'm pretty confident about that. However, the RAM_OFFSET on the 700D is written in a different format from the EOSM:

stubs.S

Code: [Select]

#define RAM_OFFSET (0xFFA5E8B0-0x1900) // Nanomad: some functions are copied to RAM at around ff0c0098; they have to be called from RAM...

Oh boy. I would assume that the RAM_OFFSET is 0xFFA5CFB0 but there must be a reason it is written the way it is.

Running find_free_edmac_channels seemed pretty straight forward but --

edmac-memcpy.c

Code: [Select]

#ifdef CONFIG_700D
// channels 0 and 8 "seems to work" with find_free_edmac_channels
// but these values don't work. Still searching.
uint32_t raw_write_chan = 20;
#endif

I tried every channel from 0-20 and found several that seemed to work but the MLV file was just a bunch of noise. The EOSM is written in hex (0x12) while the other platforms are in decimal values so maybe theres a reason for that too?

Sorry to be a PITA but it seems that config_edmac_raw_slurp on the 700D is possible if we can find the right numbers to plug in. Here's my latest work in progress:

Code: [Select]

diff --git a/platform/700D.114/internals.h b/platform/700D.114/internals.h
--- a/platform/700D.114/internals.h
+++ b/platform/700D.114/internals.h
@@ -139,3 +139,7 @@
 
 /** Workaround for menu timeout in LiveView */
 #define CONFIG_MENU_TIMEOUT_FIX
+
+/** this method bypasses Canon's lv_save_raw and slurps the raw data directly from connection #0 */
+#define CONFIG_EDMAC_RAW_SLURP
+
diff --git a/src/edmac-memcpy.c b/src/edmac-memcpy.c
--- a/src/edmac-memcpy.c
+++ b/src/edmac-memcpy.c
@@ -396,6 +396,12 @@
 uint32_t raw_write_chan = 4;
 #endif
 
+#ifdef CONFIG_700D
+// channels 0 and 8 "seems to work" with find_free_edmac_channels
+// but these values don't work. Still searching.
+uint32_t raw_write_chan = 20;
+#endif
+
 #ifdef CONFIG_EOSM
 uint32_t raw_write_chan = 0x12;
 #endif
diff --git a/src/raw.c b/src/raw.c
--- a/src/raw.c
+++ b/src/raw.c
@@ -118,6 +118,10 @@
 #define DEFAULT_RAW_BUFFER MEM(0x404E4 + 0x44)
 #endif
 
+#ifdef CONFIG_700D
+#define DEFAULT_RAW_BUFFER MEM(0x25B0C + 0x3C)
+#endif
+
 #else
 
 /* with Canon lv_save_raw, just read it from EDMAC */
@@ -447,6 +451,12 @@
     return 1;
     #endif
 
+    #ifdef CONFIG_700D
+    *width  = zoom ? 2592 : mv1080crop ? 1872 : mv720  ? 1808 : 1808;
+    *height = zoom ? 1108 : mv1080crop ? 1060 : mv720  ?  720 : 1190;
+    return 1;
+    #endif
+
     /* unknown camera? */
     return 0;
 
One last question about this:

raw.c

Code: [Select]

    #ifdef CONFIG_EOSM
    *width  = video_mode_crop ? 1872 : 1808;
    *height = video_mode_crop ? 1060 : 727;
    return 1;
    #endif

Is video_mode_crop the same as mv1080crop or is there a reason why it is coded this way for the EOSM and would this also apply to the 700D?

[dmilligan]

Well, as you know, the EOSM only has two video modes we can actually use for raw video (crop hack and mv720 - LV "standby" or whatever you want to call it), so I didn't bother looking up the buffer sizes for the other ones that only start when recording h.264. For 700D you will probably need all of them.

I believe there is method in crop_rec that avoids the hardcoded buffer sizes (have not looked at that code)

[eNnvi]

working to find addresses for 700D too.

@dfort can u pls update your repo so we'd be able to work on the same files?

had to work in the past few days so didn't had the time to write even a line

now disassembling rom and ram

[dfort]

@eNnvi -- commited what I've got so far:

https://bitbucket.org/daniel_fort/magic-lantern/commits/e0463878deec23ab856d05879def00a78e6d0d6d

[g3gg0]

Oh boy. I would assume that the RAM_OFFSET is 0xFFA5CFB0 but there must be a reason it is written the way it is.

this way you know two important informations.
where the RAM address is and from where it gets copied.

writing 0xFFA5E8B0 would throw away that information.

[dfort]

Well, as you know, the EOSM only has two video modes we can actually use for raw video...

There is a third one -- zoom. The magnifying lens icon is on one of the touch screens so it isn't very convenient to get into that mode but it has a 2592x1108 full raw buffer and allows shooting up to 2496x1074 images. Of course 24fps is out of the question but it should be usable at lower frame rates especially with the lower bit depths.

The only video mode missing on the EOSM is mv1080 or at least that buffer seems to be out of reach for now. All of the video modes except for the "Movie crop mode" (a.k.a. mv1080crop or video_mode_crop) default to 29.97fps (even when set to PAL) so this is a quirky little camera to say the least.

At some point perhaps someone will find the key to unlocking mv1080 on the EOSM. Also, lower bit depth will eventually be working on other platforms so shouldn't this work?

Code: [Select]

#if defined(CONFIG_100D) || defined(CONFIG_650D) || defined(CONFIG_700D) || defined(CONFIG_EOSM)
    *width  = zoom ? 2592 : mv1080crop ? 1872 : mv720  ? 1808 : 1808;
    *height = zoom ? 1108 : mv1080crop ? 1060 : mv720  ?  720 : 1190;
    return 1;
#endif

These are the cameras that exhibit the focus pixel issue. They all have identical full raw buffer sizes. I also made a new discovery while searching for video streams that don't show focus pixels but I'll save that post for the focus pixel topic.

[Teamsleepkid]

@dfort anything new on the dec4th build for eosm? I'm using mlv lite 1.1 raw record module. its working well in 10 bit raw. there's been a bunch of builds and i feel like I'm missing something new. haha

[dfort]

You can check up on new commits to this branch with this link:

https://bitbucket.org/hudson/magic-lantern/commits/branch/raw_video_10bit_12bit

I don't want to merge too many branches together until this is well tested. How about trying mlv_rec with mlv_snd in 10bit?

I'm also testing the latest cr2hdr.app that uses MLVFS and can't get the mlv_snd working with mlv_rec. It should work because the WAV file sounds fine. Also, applying FPS override to 23.98 causes corruption at the top 1/3rd of every other frame with mlv_rec but it is fine with raw_rec (MLV Lite).

On the EOSM using the Dec. 4 build.

[arrinkiiii]

Hi guys,  its possible to compile one for the 7D,  want to make some testing

Thanks   

[dfort]

Hi guys,  its possible to compile one for the 7D...

It is possible but is there anything new to report on the 7D? Correct me if I'm wrong but only the 5D3.113 and EOSM.202 are doing the EDMAC_RAW_SLURPING thing necessary for this to work properly.

working to find addresses for 700D too.

Any luck yet?

[LEVISDAVIS]

For future reference... Just wanted to jump back in and say that the 10-bit + 12-bit RAW recordings from the Nov 29 & Nov 30th build created magenta frames during 5X Crop mode for the Canon 50D. This includes the 14-bit RAW as well.

Jumping out...

[reddeercity]

So I'm wondering if this is a bug or something but doing some testing with 3xCrop mode on 5D2 with build from dfort Dec./1/2016 . Just the basic modules for raw video.
With raw_rec (mlv lite) in fine resolutions 10 & 14bit  2152x1072 is the max. selectable resolution, while in 12bit I can expand the size to 2152x1076 but not 10 or 14bit.
Should it not but the same thought out the bit range ? Too bad the image are dark pink not very easy to correct like bad black levels , Good thing thou is in 12bit with Full MLV+audio in
3X crop mode I have perfect corruption Free recording  with correct black levels in All Liveview modes , but only the canon preview was glitch free no Lv freeze or B/W lines mess .
Thou framing is off it doesn't freeze up very useable and with audio too . I didn't try 10 bit in 3x Crop to see if it's a problem will try later , so it seems 3x crop recording to MLV 2.0(full)
 works in 12bit  corruption free (useable).

Edit: Sorry the size in 3xcrop MLV 2.0(full) was 2144x1076 @23.976p

[arrinkiiii]

Thanks dfort. I thought that exist, even with bad frames, a version for the 7D 

[nikfreak]

There's one in the 7D thread posted by me.

Edit: http://www.magiclantern.fm/forum/index.php?topic=9848.msg175503#msg175503

That one is confirmed to work

[arrinkiiii]

Thanks nikfreak      Will test it and give some feedback.

[robertgl]

@660 re:50D

What resolutions & frame speeds did you shoot at? You did not get repeating frames or torn frames?  thanks

[ilia3101]

@reddeercity

10 & 14bit  2152x1072 is the max. selectable resolution, while in 12bit I can expand the size to 2152x1076 but not 10 or 14bit.
Should it not but the same thought out the bit range ?

(If I understand it correctly): The whole image has to be a multiple of 16 bytes, and 1076x2152 in 14 bit is not, so it reduces vertical resolution. In new 1880, the max vertical resolution is 1248 instead of 1250, highest resolution you can get is 1872x1250 in 12 bit.

[eNnvi]

ok i'm stuck on a (probably) stupid thing: find the right address for raw_slurp

i disassembled my 700D .bin file, i found the lv_raw_dump function in rom but i don't get how to get the right address from here.

I mean..

Code: [Select]

ff36c804: 725f766c subsvc r7, pc, #108, 12 ; ff36c7a0: (72615020)
ff36c808: 645f7761 ldrbvs r7, [pc], #-1889 ; ff36c810 <_binary_ROM1_BIN_start+0x36c810>
ff36c80c: 00706d75 rsbseq r6, r0, r5, ror sp
ff36c810: ff36beb0 ; <UNDEFINED> instruction: 0xff36beb0
following http://www.magiclantern.fm/forum/index.php?topic=5601.msg175969#msg175969 dmilligan says there should be a branch instruction but i don't get where it actually is. I mean the subsvc should mean something like

Code: [Select]

r7 = pc - (108<<12) right?

[g3gg0]

this is no valid code.

[reddeercity]

@reddeercity(If I understand it correctly): The whole image has to be a multiple of 16 bytes, and 1076x2152 in 14 bit is not, so it reduces vertical resolution. In new 1880, the max vertical resolution is 1248 instead of 1250, highest resolution you can get is 1872x1250 in 12 bit.

No you misunderstood , I'm talking about 3x crop mode not full frame with the new 10-12 raw_rec (mlv lite) with a1ex update fine resolution's , in 10 bit & 14 bit in 3xCrop mode 1072 is maximum vertical and 12bit can be expanded to 1076 on the same build . It shouldn't matter if it's 10 , 12 or 14 bit the  vertical resolution in 3x crop should not change & yes I understand what happen with the code . If you check out the full MLV 2.0+audio in 3x crop mode the maximum vertical resolution is 1076 and of course in 12bit (mlv2.0) @ 2144x1076 all frames are clean with Canon Liveview .

Edit: On MLV 2.0 with bit range reduction (10-12bit) update in 3x Crop the maximum vertical resolution stays the same thou out all 3 bit ranges of 1076
 

[reddeercity]

5D2 , To just confirm MLV 2.0 10bit in 3X crop @ 2144x1076 23.976p + audio are free of any corruptions/shearing etc... .  with Canon Lv.

[reddeercity]

So I been trying to correct the pink/magenta 3x Crop on 5d2 with raw_rec(mlv lite) with reduced bit range (working with 12bit)
well exiftool tell me the white & black level are totally out to lunch compared to mlv 2.0 in crop mode
I end up with black level of 63 & white level of 937 on the magenta frame and on the non magenta frame (full mlv2.0) black level 448 & white level 3750.
Not sure why mlv lite uses these level compared to mlv2.0 which are correct , anyway to fix the magenta frames  I used Exiftool to set the white & black level
to what my eyes see as normal WB image. So after some time of trial & error I set the black level to 110 and the white level to 730 ,
it doesn't seem right to have just a little differences between the
black & white levels as compared to the other images levels below is the magenta frame and then the corrected frame with exiftool.

 
12bit_3Xcrop magenta frame by RedDeerCityTV, on Flickr


12bit_3Xcrop_corrected_levels by RedDeerCityTV, on Flickr

syntax for windows in command prompt
exiftool -IFD0:BlackLevel=110 *.dng
exiftool -IFD0:whiteLevel=730 *.dng
If anyone what's to check the original magenta Cdng frame 2144x1076  link below
https://www.dropbox.com/s/91a1blyb2qix31f/original_M08-0008_000004.dng?dl=0

[rbrune]

No you misunderstood , I'm talking about 3x crop mode not full frame with the new 10-12 raw_rec (mlv lite) with a1ex update fine resolution's , in 10 bit & 14 bit in 3xCrop mode 1072 is maximum vertical and 12bit can be expanded to 1076 on the same build . It shouldn't matter if it's 10 , 12 or 14 bit the  vertical resolution in 3x crop should not change & yes I understand what happen with the code . If you check out the full MLV 2.0+audio in 3x crop mode the maximum vertical resolution is 1076 and of course in 12bit (mlv2.0) @ 2144x1076 all frames are clean with Canon Liveview .

Edit: On MLV 2.0 with bit range reduction (10-12bit) update in 3x Crop the maximum vertical resolution stays the same thou out all 3 bit ranges of 1076

No, he is right, the bit depth matters. You can check with some simple math:

Code: [Select]

((2152*1072*10bit)/8bit)/16bytes = 180230
((2152*1072*12bit)/8bit)/16bytes = 216276
((2152*1072*14bit)/8bit)/16bytes = 252322

((2152*1076*10bit)/8bit)/16bytes = 180902.5
((2152*1076*12bit)/8bit)/16bytes = 217083
((2152*1076*14bit)/8bit)/16bytes = 253263.5
Only modes that give an integer value are valid and can be used to record with. So yes you can record with 12bit @ 2152x1076 but not with 10/14bit.

[D_Odell]

Tried to read me to understanding this build but I can't manage to record without getting pink pixelated images. Live view is only stripes of black and white. Does it work on exfat? I have only tried in crop mode. Thanks!

[reddeercity]

No, he is right, the bit depth matters. You can check with some simple math:

Code: [Select]

((2152*1072*10bit)/8bit)/16bytes = 180230
((2152*1072*12bit)/8bit)/16bytes = 216276
((2152*1072*14bit)/8bit)/16bytes = 252322

((2152*1076*10bit)/8bit)/16bytes = 180902.5
((2152*1076*12bit)/8bit)/16bytes = 217083
((2152*1076*14bit)/8bit)/16bytes = 253263.5
Only modes that give an integer value are valid and can be used to record with. So yes you can record with 12bit @ 2152x1076 but not with 10/14bit.

Thanks for the math , so then as per example when I'm using mlv 2.0 @ 12bit 2144x1076

Code: [Select]

((2144*1076*12bit)/8bit)/16bytes = 216276If I did my math right "216276" is a good  integer value , so valve that fall in to the ".5" etc... don't work right ?