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

[reddeercity]

I can confirm on 5D2 1880 does work in all bit ranges , of course it's only stable/uncorrupted in 14bit
10 , 12 have issue of course but liveview never froze up . I didn't have time today to recompile
the 10_12bit expermential branch so I tested out dfort build as it seem to be update .
Set liveview to Auto , FYI . I made 3 short 20 second test videos (h264) from 10 ,12 ,14 bit
in my Dropbox  https://www.dropbox.com/sh/lh5lxr74moyrnj5/AAAFDzHGYxoafVLWkX71R5R0a?dl=0
you can there download (50MB each) or watch them in dropbox
Beware ! 10 & 12 bit may made you sea sick 

[dfort]

@reddeercity

Are you using mlv_rec or raw_rec (MLV Lite)? I've gotten better results on the EOSM from raw_rec.

[a1ex]

Did some changes to raw_rec (mlv lite), not really related to bit depth, but since this became the "de facto" bleeding edge branch for raw recording, I've merged them. The functional ones are:

- fix for this issue (may affect recording times if - and only if - global draw is on).

- a change borrowed from mlv_rec (async edmac calls) that might help with general frame corruption issues (that already happen in unified in some edge cases); it will not help with frame corruptions related by bit depth changes.

Currently benchmarking these changes; will post results here.

For new builds, I recommend including only those cameras that can record without corrupted frames, at least at some settings. For the cameras that show corruption every other frame, the behavior will be unchanged. I know the cause and already suggested possible fixes a month ago. Until somebody implements one of these fixes (hint: see how it was done on EOS M), reports of image corruption (repeated for every new build), for those models that are already known not to work, are simply not useful.

[Peter Linov]

5DMIII 1.2.3 
CRASH 00-
ASSERT: hLvJob->hJpegMemSuiteat ./Epp/Vram/VramStage.c:891, task Epplv:1 mode:3
Magic Lantern version : Nightly.2016Dec01.5D3123 Mercurial changeset   
: 385bc44ed158+b3dfbe7194f3+ (5D3-113_123_10bit_12bit) tip
Built on 2016-12-01 23:09:48 UTC by rosiefort@RosieFoComputer.
Free Memory  : 146K + 3712K
CRASH01-
ASSERT: IsSuiteSignature( hSuite ) at ./PackMemory/PackMem.c:599, task Epp
lv:0 mode:3Magic Lantern version : Nightly.2016Dec01.5D3123
Mercurial changeset   : 385bc44ed158+b3dfbe7194f3+ (5D3-113_123_10bit_12bit) tip
Built on 2016-12-01 23:09:48 UTC by rosiefort@RosieFoComputer.
Free Memory  : 146K + 3728K
CRASH02-
ASSERT: hLvJob->hJpegMemSuiteat ./Epp/Vram/VramStage.c:891, task Epp
lv:1 mode:3 Magic Lantern version : Nightly.2016Dec01.5D3123
Mercurial changeset   : 385bc44ed158+b3dfbe7194f3+ (5D3-113_123_10bit_12bit) tip
Built on 2016-12-01 23:09:48 UTC by rosiefort@RosieFoComputer.
Free Memory  : 153K + 3719K

[dfort]

@Peter_Linov

Didn't think it was going to work but it was worth a shot. What were the conditions that caused the crash?

Looks like for now we should limit the test builds to the 5D3.113 and EOSM.202 and make sure we're in raw_rec instead of mlv_rec. These test builds don't have the mlv_rec and mlv_snd modules to avoid confusion.

https://bitbucket.org/daniel_fort/magic-lantern/downloads/magiclantern-10bit_12bit_raw_twk_crop_rec.2016Dec01.5D3113.zip
https://bitbucket.org/daniel_fort/magic-lantern/downloads/magiclantern-10bit_12bit_raw_twk_crop_rec.2016Dec01.EOSM202.zip

[teatotalTED]

The 550D is also very close, 12bit works fine, 10bit image intact just 16 pixel offset to right every other frame, (mlvrec not rawrec which looks to be a trainrec on the 550D)

A1ex suggests above that there's a fix for this from a month ago or should this be brought up on the 550D camera specific thread instead of here where priorities seem weighted elsewhere, I guess because of ownership of EOS-M & 5D3? There's many more 550D ML users than EOS-M and for good reason?

[DeafEyeJedi]

... There's many more 550D ML users than EOS-M and for good reason?

I'd take an EOSM over 550D on any given day and no pun intended.

[dfort]

The 550D is also very close...

I didn't know that. Here's a test build for the 550D without mlv_rec and mlv_snd like the other test builds I recently posted.

https://bitbucket.org/daniel_fort/magic-lantern/downloads/magiclantern-10bit_12bit_raw_twk_crop_rec.2016Dec01.550D109.zip

[hammermina]

@dfort

550d build works :)12 bit all resolutions
10 bit frames are messed up...

go for it

[teatotalTED]

12bit worked great via mlvrec in dforts build from before, so 12bit now works in rawrec to.

10bit in rawrec is vertically jumping up and down 16 pixels every other frame rather than moving to the right 16 pixels every other frame as with the mlvrec module from dforts earlier build.

[dfort]

@teatotalTED

Actually it is the same build. What you are reporting is the difference between mlv_rec and raw_rec (MLV Lite).

[reddeercity]

@reddeercity
Are you using mlv_rec or raw_rec (MLV Lite)? I've gotten better results on the EOSM from raw_rec.

raw_rec (mlv lite) actually it's getting better on 5D2  , 10bit used to be totally pink noise & 12bit ever other frame was totally pink noise.
But ever once in a while I have perfect recording + clean liveview mostly in Crop mode . I would say crop mode on 5d2 is more stable right now .

[teatotalTED]

The same build? As yours from yesterday posted at 12.08:58? How can it be the latest doesn't have mlvrec and mlvsnd in it? Might be same code base but a new build? 12bit on 550D worked fine on yesterdays build of 12.08:58 via mlvrec, all I was saying was that 12bit working on 550D was nothing new to the latest rawrec only build. And finally yes I was comparing 12.08:58 build 10bit 550D via mlvrec 16 pixel shift horizontal with latest rawrec only build 10bit 16 pixel shift vertical, both very close to solution for 550D, so to first say only concentrate on EOS-M and 5D3, then say only concentrate on rawrec, with regard to 550D either which way makes little difference its so close. Does the latest rawrec build include possible fix highlighted by A1ex in post #627, is that what we're supposed to be testing here in the latest build?

[a1ex]

That's a race condition working in your favor

The process is very sensitive to timing, and will be so until the real issue is addressed. The DMA channel is configured for 14-bit image size, we only copy 12-bit (or 10-bit) data from it, and what happens with the excess data... Canon knows. That's the cause of the artifacts you describe. It is a random process, as the LiveView timings are not very exact (I think the image capture is done at fixed intervals, but the processing timing is affected by the task scheduler, to some extent).

So, just because it works for you in some (lucky) conditions, that doesn't mean it's getting any closer.

[teatotalTED]

Yeah anticipated the response to presumption of 'so close', in reality I'm well aware it ain't that simple, just would like to see 550D in the running, 10bit on cameras with restricted write speeds is a good priority to many users, for me my 50D is go to and barely use the 550D. Lucky settings, there's no blackmagic, pun intended, in the combination of settings, just chose mlvrec 10bit and it either works or doesn't, don't consider myself a tester just have bit of time at the moment to mess.

[kyrobb]

Tried out dfort's latest build on the 550D. In 10 bit every second frame is perfect, but in the others only the top 3rd is correct. The bottom 2/3rds are just a repeat of the 1st frame I believe. Liveview still works great and the record times are awesome!

[zcream]

From Post #22
>>
Reading this: http://francoismalan.com/2011/10/raw-12bit-or-14bit-lossy-or-lossless/
... i guess that it would only make a very very slight difference!

If this is really working... I just dont have words for how awesome this is...
>>

Here is the other argument..
>>
There is a difference between underexposed sunny scene and shooting in pitch dark interiors or at night.

I did the tests myself and 14 bit has huge advantage under extreme dark conditions.

Compression concerns the highlights only and I assume it works the same way for the high-key scenes – white on white.

It’s true, in every-day outdoors shooting, 14bit/uncompressed doesn’t really matter.

[dfort]

New test builds:

https://bitbucket.org/daniel_fort/magic-lantern/downloads/magiclantern-raw_video_10bit_12bit.2016Dec04.5D3113.zip
https://bitbucket.org/daniel_fort/magic-lantern/downloads/magiclantern-raw_video_10bit_12bit.2016Dec04.EOSM202.zip

Seems like we may be adding too much into the recent test builds like crop_rec and raw_twk and reporting the results in this topic. How about we test just a few things at a time like raw_rec and mlv_rec and make sure to indicate which one you are using in your reports.

Also, cameras other than the 5D3.113 and EOSM.202 should be updated before making more test builds for those platforms:

For new builds, I recommend including only those cameras that can record without corrupted frames, at least at some settings. For the cameras that show corruption every other frame, the behavior will be unchanged. I know the cause and already suggested possible fixes a month ago. Until somebody implements one of these fixes (hint: see how it was done on EOS M), reports of image corruption (repeated for every new build), for those models that are already known not to work, are simply not useful.

[dfort]

Did some more research and it seems that the cameras that have the fewest issues are the ones that have CONFIG_EDMAC_RAW_SLURP. Looks like dmilligan got it working on the EOSM.

According to the features list the 60D and 600D have this feature. Anyone out there want raw_video_10bit_12bit builds of those platforms to test?

[Levas]

I've recorded in 10bit, many times, on the 6d and there are no corrupted frames, both in raw_rec and mlv_rec modules.
Only problem is that liveview freezes (no config_edmac_raw_slurp).
I'm stuck with figuring out how to find the address for the 6d to configure config_edmac_raw_slurp(see few post back in this topic).
http://www.magiclantern.fm/forum/index.php?topic=5601.msg175682#msg175682

But I can assure, that there are no corrupted frames on the 6d with 10bit recording.
Although 12bit has sometimes the purple banding issues on every frame.

[g3gg0]

Only problem is that liveview freezes (no config_edmac_raw_slurp).

disabled raw_twk module?

[Levas]

With and without raw_twk enabled, live view freezes during 10bit recording on 6d.
But as far as I know, you need to configure config_raw_edmac_slurp to fix this.
At the moment this only done for 4 cams, 5d3, eosm, 60d and 600d

With 14 bit, live view works like it should be.

[dfort]

@Levas - I'm trying to do the same with the 700D and seem to be stuck in the same spot you were in a week ago.

I ran find_free_edmac_channels and found that channels 0 and 8 "seems to work" but I have no idea where to find the DEFAULT_RAW_BUFFER MEM address. I've got an EOSM so I'm looking a disassembly of the ROM1.BIN. Found "lv_raw_dump" but don't understand how dmilligan got MEM(0x404E4 + 0x44) out of that.

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,11 @@
 uint32_t raw_write_chan = 4;
 #endif
 
+#ifdef CONFIG_700D
+// channels 0 and 8 "seems to work"
+uint32_t raw_write_chan = 8;
+#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,11 @@
 #define DEFAULT_RAW_BUFFER MEM(0x404E4 + 0x44)
 #endif
 
+#ifdef CONFIG_700D
+// copied from EOSM -- need to find 700D address
+#define DEFAULT_RAW_BUFFER MEM(0x404E4 + 0x44)
+#endif
+
 #else
 
 /* with Canon lv_save_raw, just read it from EDMAC */

[EDIT] Seems like this was tried before on the 6D:

http://www.magiclantern.fm/forum/index.php?topic=13155.msg127251#msg127251

[dmilligan]

At the beginning of lv_raw_dump on the M there is a call made to a function in ram (branch instruction). On 60D this function call is to ROM not RAM. We can use RAM_OFFSET to find the location of that function in rom (Canon firmware copies some functions to RAM and runs them there rather than running them directly from 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

This code loads 0x404e4 into register 0, then adds 0x44 to register 0, then it returns (register 0 is the return value). In C:

Code: [Select]

return 0x404e4 + 0x44;

On 60D:

Code: [Select]

FF0F8B8C: ldr r0, [pc, #732] ; 0xff0f8e70: pointer to 0x4ff8 FF25B020 FF25B360 FF25B3A4 FF25AF2C FF25B31C
FF0F8B90: ldr r0, [r0, #48] ; 0x30
FF0F8B94: ldr r0, [r0]
FF0F8B98: bx lr
Which is equivalent to:

Code: [Select]

return *(0x4ff8 + 0x30);

Then lv_raw_dump uses this return value as a pointer to the location of the raw buffer. The ML macro MEM() is simply a pointer dereference. So Canon firmware always keeps a pointer to the location of the raw buffer at 0x404e4 + 0x44 on the EOS M. The actual raw buffer may be dynamically allocated, but it's current address is always kept at memory address 0x404e4 + 0x44 (yes, this is a pointer to a pointer, on 60D, it's actually a pointer to a pointer to a pointer). I guess these buffer addresses are probably kept in static arrays or structs and the + 0x44 part is the array index or struct offset. If it is indeed a data structure, it might be interesting to look at and around 0x404e4 and see what else might be kept there.

[capncannabis]

Is there a build to test this on the 600d?