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

[dfort]

That I complied with the change I did (mainly the write channel ) ( the one that a1ex said not to use but works in 1:1)

Interesting, you changed the write channel and 1:1 works again?

@alex, I've been thinking about the discovery that my experimental builds for the LVState Digic 4 cameras work better when you first use it then it gets into the "earthquake" mode. Maybe the buffer needs to be cleaned out before recording? I'm not really sure how all this works but it seems that there is something left over in the buffer that throws things out of whack. Deleting the ML settings, restarting the camera, set mlv_lite or mlv_raw to 10/12bit and chances are it will work.

[reddeercity]

Interesting, you changed the write channel and 1:1 works again?

Yes , changed write channel from 0x01 to 0x02 in edmac-memcpy.c

Also here I did test your original 10-12bit build from my downloads in bitbucket  10bit_12bit_raw_twk_crop_rec.2016Dec01.5D2212.zip there I only tested full mlv+audio and as you know 3x crop work perfectly with bit reductions , mainly I record 10bit @ 2144x1076 23.976p and 1:1@ 12bit does work with the top 100 or so lines being corrupted but still useable (just crop off the bad part) . Be on that there not other problems , it just has the 10-12bit code implemented without RAW_SLURP .
See image below , 1st is 12bit 1856x1044 @ 23.976p 2nd is the next frame in the sequence .
 
https://bitbucket.org/reddeercity/magic-lantern_10-12bit/downloads/12bit_M18-0124.MLV --- here is the only 12bit 1:1 I got to work without any corruption (190MB) from  ‎March ‎04, ‎2017,
But for the life of me I can't remember what I changed and I can't find the source code right now 

[reddeercity]

Found something that may help a little How do State Machines change states? ok maybe not
@dfort
Found something that may be helpful from raw.c-104

Code: [Select]

#ifdef CONFIG_7D
//~ #define DEFAULT_RAW_BUFFER MEM(0x2b14)
//~ #define DEFAULT_RAW_BUFFER shamem_read(0xC0F26008)
#define DEFAULT_RAW_BUFFER 0x43C0D24
//~ #define PREFERRED_RAW_TYPE 16
//~ #define RAW_TYPE_ADDRESS 0x1D38
#endif
It a old experiment from @onepercent , this may be in the backend of the code but I could not find it .I know it's not raw_slurp but
Hope it's helpful

[andrew_dotdot]

Sound on the 70D?

I'm a longtime Magic Lantern user, but this part of ML really has a steep learning curve.

I have a 70D and the 12-bit modules are installed and they load and I get video in 10 12 and 14 bit (yay!) using mlv_lite/raw_rec, mlv_play and raw_twk -- but SOUND? Not so much. I look in the MLV with MLVFS, and there's no .wav.

In the past, I've used old-regular MLV with good results and sound, but then you have the mlv_snd module -- and no such module exists in the modules directory of the 70D 12-bit download; and (not unexpectedly) bringing in a mlv_snd module from another build doesn't work at all.

Is the sound working in the 70D at all, and if so, how does one get that working?

Thx so much for this branch of the ML experience!

:A)>

[dfort]

EOSM2: ? (requires merging)

Filling in the blanks:

EOSM2: 48798100 - 48CC40C4

Here's the Free Memory screen:



Like the EOSM it starts in mv720 mode:



Looks like it is crying out for help. Not able to make screenshots and the console keeps shrinking down so it is impossible to read the information needed for DEFAULT_RAW_BUFFER_SIZE.

zoom mode:


mv1080crop mode:


Raw buffer sizes pretty much as expected.

[saulbass]

Some console screens from 650D using dforts - allocate-raw-lv-buffer.2018Feb25.650D104.zip

I tried changing photo/video/lv/crop/720p/1080p modes but the numbers seem to stay the same.

[dfort]

I tried changing photo/video/lv/crop/720p/1080p modes but the numbers seem to stay the same.

Did you try starting the camera with mlv_lite active? You can also start with mlv_lite off then turn it on and it should update:

- open the console (Debug menu) and enable something that uses LiveView RAW features (raw video, raw histogram etc)
- test by starting the camera in all video modes (photo, 1080p, 720p, crop, x5 etc)

If the camera cannot start in the tested mode, you can start the camera with raw video turned off, then switch to that mode (x5, crop mode, whatever), then enable raw video. The raw buffer size detection is performed once, right before this buffer gets filled with data (it's harder to do it afterwards).

[saulbass]

Did you try starting the camera with mlv_lite active? You can also start with mlv_lite off then turn it on and it should update:

unfortunately trying repeatedly with the allocate-raw-lv-buffer.2018Feb25.650D104 build, its not possible to activate mlv_lite or crop_rec

[dfort]

unfortunately trying repeatedly with the allocate-raw-lv-buffer.2018Feb25.650D104 build, its not possible to activate mlv_lite or crop_rec

That's very strange. Ok, so according to the instructions:

The test can be done on either on the allocate-raw-lv-buffer branch (possibly better for older models), or on the current crop_rec_4k branch. I don't expect this to affect the results in any way, so just pick one. If it doesn't work, pick the other.

I tried compiling crop_rec_4k with CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP (config-defines.h) but ran into this:

Code: [Select]

../../src/boot-hack.c: In function 'copy_and_restart':
../../src/boot-hack.c:109:5: error: implicit declaration of function 'memset64' [-Werror=implicit-function-declaration]
     memset64(0x00D00000, 0x124B1DE0 /* RA(W)VIDEO*/, 0x1FE00000 - 0x00D00000);
     ^
cc1: some warnings being treated as errors
make: *** [boot-hack.o] Error 1

Got past that by copying the memset64 code from the allocate-raw-lv-buffer in stdio.c and mem.h but it wasn't showing the "Raw buffer guess" in the console so I didn't post the build. There's also memset64 in zebra.c that replaces a large block of memset calls and in mem_bench.c that is identical in the two branches.

Bottom line, I gave it a shot but the compile errors should be fixed and tested by someone with more experience than me before the crop_rec_4k branch will be able to run this test.

[saulbass]

dfort, I had another go with your "allocate-raw-lv-buffer.2018Feb25.650D104.zip" and it would appear that the problem may lie with the crop.rec module. If I switch on the console and then load mlv-lite and reboot - everything initially looks okay. But when I then load the crop-rec module - both modules appear with a 'Er' sign after rebooting. Similarly if I load the crop-rec first - I get a straight croprec 'Er' on rebooting.

Not sure if this is of any help.

[dfort]

I had another go with your "allocate-raw-lv-buffer.2018Feb25.650D104.zip" and it would appear that the problem may lie with the crop.rec module.

Hum, the crop_rec module isn't in the allocate-raw-lv-buffer branch. That probably means I didn't run "make clean" in the source top directory before compiling. There is no reason to load the crop_rec for this test. The only module that should be loaded is mlv_lite. In fact the instructions a1ex gave in the commits page indicates that you should be able to do the test without loading any module:

- open the console (Debug menu) and enable something that uses LiveView RAW features (raw video, raw histogram etc)

Let's try it again. I posted a new allocate-raw-lv-buffer build for the 650D with CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP on my downloads page.

[saulbass]

dfort - I think that this build seems to work now - I've posted some images - hopefully they're what is needed. If not let me know and I will redo.

[saulbass]

4 images from a 650D switching LV on off, photo, 720p, 1080p, 1x5, 5x5.
If you need me to identify which is which let me know.
Using dforts allocate-raw-lv-buffer.2018Feb28.650D104.zip

Hope this helps.

[dfort]

Hope this helps.

It sure does. Thanks for running this test. Turned out pretty much as expected:

650D: same values as 700D/EOSM

[dfort]

Poking around raw.c so I thought I'd revisit this:

https://www.magiclantern.fm/forum/index.php?topic=5601.msg196632#msg196632

Looks like this test might have already been run on the 70D? It was run recently on the 650D so I'll add it to the Lossless Compression updates for all Digic 5 cameras pull request since this is all related. Still missing on the 100D so I posted a wake up call for 100D users.

The 600D and 1100D haven't been tested yet though there are raw_video_10bit_12bit builds for those cameras. These cameras have very limited memory so maybe the smaller DEFAULT_RAW_BUFFER_SIZE might be all these cameras can handle?

[dfort]

Did the test on 100D (hope I did it right) with latest crop_rec build (magiclantern-crop_rec_4k.2018Feb04.100D101).

Your test doesn't look right. Did you compile it yourself with CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP like in the instructions? Let me know if you need help with that.

[dfort]

The test can be done on either on the allocate-raw-lv-buffer branch (possibly better for older models), or on the current crop_rec_4k branch. I don't expect this to affect the results in any way, so just pick one. If it doesn't work, pick the other.

The 100D isn't in the allocate-raw-lv-buffer branch but when I tried defining CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP on the crop_rec_4k branch I got this:

Code: [Select]

../../src/boot-hack.c: In function 'copy_and_restart':
../../src/boot-hack.c:105:5: error: implicit declaration of function 'memset64' [-Werror=implicit-function-declaration]
     memset64(0x00D00000, 0x124B1DE0 /* RA(W)VIDEO*/, 0x1FE00000 - 0x00D00000);
     ^
cc1: some warnings being treated as errors
make: *** [boot-hack.o] Error 1

This seems to affect all platforms.

[a1ex]

Hm, I should undo b831cb1 (since memset64 has slightly different behavior from standard memset, and this code relies on that). BTW, nobody noticed Magic Zoom focus confirmation is broken because of that?! It happened on all experimental builds 2 weeks ago, on all camera models...

(I'm sorry, I no longer use the camera often enough to notice such quirks, but I was hoping the others do...)

[Majkovic]

I did that tests with dforts build for 100D.
https://drive.google.com/open?id=1wFWKtmashdtGA8ult5H3GYUXbeK8zL7U

[OlRivrRat]

       Link to images of tests > I Hope !

https://photos.app.goo.gl/59Y19hUcS8TtJ1lu1

[dfort]

@Majkovic and @OlRivrRat - Thanks for the tests!

100D: 46798100-46CC40C4

Wondering if that "FIXME" message anything to worry about? Got the same on the EOSM2.

Code: [Select]

Raw buffer guess:  46798100-46CC40C4 (5.2MB, using 9.0MB FIXME)

[a1ex]

Unless somebody starts porting the 4K and full-res LiveView on these cameras, it won't make any difference. These size checks will never be triggered with default LiveView resolutions; these code changes are more about future-proofing the codebase. Well, some years ago we suspected the 1100D might have a smaller buffer (for some reason, it didn't work, and - not knowing what we were doing - we believed it was that, as it worked fine with a custom buffer). Turns out it was a mistake - the 1100D raw buffer is large enough for all LiveView resolutions (estimated by counting the pixels from the Free Memory screenshot; still need to run the same test to find out the exact value).

100D/EOSM2 x5: 2592 * 1108 * 14/8 = 5025888 (smaller than 5.2MB).

On 700D, these changes were already helpful.

[reddeercity]

Battle testing the 10-12bit broken 3xcrop5D2212  LVState-wip branch from dfort ,  to see what bricks it . As we know the write channel  I'm using (0x2)has a very small amount of data being written to as a1ex said .
We do know that this build breaks 3x Crop_mode , hence the name . HDMI does not brick it , connected at bootup & after ml running plugged it in & no problems , thou the liveview was slow almost seems to running a half speed (18-12fps) once recording started  liveview returned to normal speed (no delay)(without HDMI connected) (D4/5D2 kills the ml overlays with full mlv+audio , clean output recordable) , did notice to 10x zoom the black levels was bad (pink-ish normally is canon liveview) 5X zoom or 3X Crop mode was normal .

Frame override was enable to 23.976 , so no problems there -- audio was enable to 44.1 kHz , no problems again . The only issue I had that cause a lockup/frozen liveview (needed a battery pull) when I changed the ISO I always use analog pure ISO 100 , 200 , 400 & sometimes 800 not digital pushed or pulled and when I move the dial to change ISO I landed on a digital one (320) & it locked up  quick battery pull and I was back in business . I could reproduce the lockup at every digital ISO , the pure ISO's all work without lockup up to 1600 ISO (yes it pure also , found that out in my disassembly) .  After I got the right ISO (200) I proceeded to set to 12bit @ 1856x1044+audio , started to record a 7+ min talking head , 30GB had a skipped frame at 11299 frames so it stop , I was done just before that by a few seconds . It was a perfect recoding no corruption , the 1st frame had out of sync image bit the rest are all good (perfect) . I didn't use 10bit , thou I did test it and not problems other then the digital ISO thing , I find there's more noise
then I like (I filmed in doors with less then desirable light conditions ) so shadow get noisy when pushed in post.

What does all this mean , not sure but it is usable , but then again it could blowup and you get to kept all the parts 
If anyone want's to use it for a project you must test test test & hope doesn't it lockup (more then likely it would be ok) but Great Caution must be Observed

[dfort]

Worked with andy kh on the 70D and came up with this:

70D: 4B328000 - 4CFFFFFC (repeatable; tested mv1080, x5)



mv1080


5x zoom

[reddeercity]

started to grade the experimental 12bit @1856x1044 1:1 from my 5D2 very nice , I don't what to post a lot of images here (I make post somewhere else)
so I'll post links to the orginal dng's & the export from CS6 A.E. also the graded frame exports for FCPX with
film convert pro , I used the RED MX camera source profile (closest to raw footage) .
By the way it's just my ugly old face -- so you being warned 
M11-0006_002688.dng  no-grade.png  full grade_black backgound   full grade_white backgound

Edit:shot at 70mm (24-70f2.8L canon) F4 200 ISO @ 1/53th second (closest I can get to 1/48) and no preprocessing with mlv_dump option