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 1 Guest are viewing this topic.

Andy600

@a1ex - I just compiled the edmac module. Is there anything useful I can provide you from the 50D?

movie mode was off for this:



and on for this:



0x02 looks good and compared to the 7D where the largest channel appears to be 0x10 it makes sense with my findings!? (unless I'm not properly understanding this :-\)

also, the camera freezes when I press 'log EDMAC usage'
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

a1ex

This says channel 1 seems free (does it also come up as free if you scan for free channels?), but channel 2 is used (and a transfer was active in the moment you took the screenshot). Channel 0 is used to write the HD buffer (the input data to H.264, but it's also updated in standby) and channel 18 = 0x12 writes the LV buffer (the preview image - 720x480 on 3:2 screens, about 720 x 480*(4/3)/(3/2) = 720x426 on 4:3 screens, 2 bytes per pixel - UYVY aka YUV422 in Canon strings). This matches the definitions from consts.h - just giving some examples on how to interpret these numbers.

Channel 13 is reading from the HD buffer (maybe for resizing it or whatever it does), but its geometry is likely more complex, so the overview screen only prints its size. You may scroll to detailed view to get the full configuration. We don't need it for this experiment - I'm just showing how you can use it to explore things.

The camera freeze has to be debugged (not sure where to start). Does it work outside LiveView, if you use it to log a still image capture? Does it help if you increase LOG_INTERVAL?

Then, there are a bunch of logging tools in the dm-spy-experiments branch (such as logging EDMAC transfers, or state object transitions). Sample snippet from 500D, which I'm studying for QEMU emulation (found its debug messages a bit more verbose than usual).

dm-0007.log-15329-782D1> **INT-F9h*:000928bc:00:00: *** TryPostEvent(LiveViewMgr, 0x3, 0x0, 0x0), from ff0da628
dm-0007.log-15330-78327> **INT-F9h*:00000558:99:02: WriteEDmacFlickerCompleteCBR
dm-0007.log-15331-7834E> **INT-F9h*:0000057c:00:00: <<< INT-F9h done
dm-0007.log:15332:7838F> LiveViewMg:000920c0:00:00: *** LVState: (3) --3--> (4)          ff0e1288 (x=b18710 z=0 t=0)
dm-0007.log-15333-783E7> LiveViewMg:ff0e12b0:98:02: SetPsave 0xFFFFF0 RecRes:2 LvRes:2
dm-0007.log-15334-7844A> **INT-5Eh*:00092118:00:00: >>> INT-5Eh EDMAC#9 ff18f7d8(9)
dm-0007.log-15335-78488> **INT-5Eh*:00092198:00:00:     addr 734fd4, ptr 736474, size , flags 0
dm-0007.log-15336-784CB> **INT-5Eh*:0000057c:00:00: <<< INT-5Eh done
dm-0007.log-15337-784EF> **INT-5Dh*:00092118:00:00: >>> INT-5Dh EDMAC#8 ff18f7d8(8)


In these logs, messages tagged with *** are from our logging handlers (such as the LVState transition - state_transition_log), the >>> and <<< are showing interrupts, while plain messages (not tagged with anything) come from Canon code. The dm-spy-experiments code is pretty much a swiss army knife and requires fiddling - you may place logging hooks basically anywhere in Canon code (whenever you think they may provide useful info). Start by using predefined logging functions, then feel free to invent new ones. Caveat: some of them may conflict, depending on their ROM address, so you can't just enable them all at the same time. Refer to the dm-spy-experiments topic for details.

Example of messages I could only find on 500D (full log, without raw):

dm-0010.log:4326:E6762>    Startup:ff170334:9b:01: TG-InitializeLvTgDriver
dm-0010.log:4327:E6816>    Startup:ff17039c:9b:01: dwInitComm[0]=0x12800001
dm-0010.log:4328:E6863>    Startup:ff1703c8:9b:01: wInit[0]=0x00000000
dm-0010.log:4329:E6896>    Startup:ff1703f4:9b:01: dwInit[0]=0x00074046
dm-0010.log:4330:E68E7>    Startup:ff170424:9b:01: pAdjustAnalgVoltage[0][0]=0x00140000
dm-0010.log:18305:222F2> LiveViewMg:ff170580:9b:01: TG-PowerOnLiveViewDevice
dm-0010.log:18306:2231A> LiveViewMg:ff17059c:9b:01: PowerOnE3LAT
dm-0010.log:18360:2377F> LiveViewMg:ff1705d4:9b:01: PowerOnE31LAT
dm-0010.log:18395:25F5B> LiveViewMg:ff170624:9b:01: CancelADTG_RESET
dm-0010.log:18396:25F85> LiveViewMg:ff170644:9b:01: EnableSerialPort
dm-0010.log:20113:4419C> LiveViewMg:ff170680:9b:01: TG-ReadyLiveViewDevice
dm-0010.log:20114:441BF> LiveViewMg:ff1706a4:9b:01: 2-1.AFE_InitSetting 74046 2804c
dm-0010.log:20169:44ABA> LiveViewMg:ff1706d4:9b:01: 1-1.TG_InitSetting 12800001 11a42c01
dm-0010.log:20459:48A39> LiveViewMg:ff170764:9b:01: PowerOnE32LAT
dm-0010.log:20460:48A63> LiveViewMg:ff17077c:9b:01: 2-2.BaseVoltage_Setting
dm-0010.log:20471:48C33> LiveViewMg:ff1707a0:9b:01: 3-1.CMOS_InitSetting
dm-0010.log:20494:48F9D> LiveViewMg:ff1707bc:9b:01: 1-2.2Acc1SettingForLV
dm-0010.log:21327:5B493> LiveViewMg:ff170d8c:9b:01: TG-StartupLiveViewDevice 4
dm-0010.log:21328:5B4B8> LiveViewMg:ff170d30:9b:01: 1-4/1-12.ReadOut_Setting
dm-0010.log:21336:5B615> LiveViewMg:ff170dbc:9b:01: 1-6.Condition_Setting
dm-0010.log:21341:5B6DD> LiveViewMg:ff1709f4:9b:01: 2-7.AFE Timing3[0] 92b0b bab0b
dm-0010.log:21349:5B82C> LiveViewMg:ff170ab4:9b:01: 2-3.AFE_GainSetting
dm-0010.log:21360:5B9E8> LiveViewMg:ff170dec:9b:01: 2-4.Cal_Start
dm-0010.log:21365:5BAA6> LiveViewMg:ff170e10:9b:01: 1-8.Release_PSAVE
dm-0010.log:21370:5BB6D> LiveViewMg:ff170e38:9b:01: 1-10.AnimComm_Setting [4]
dm-0010.log:21751:5FB72> LiveViewMg:ff170be0:9b:01: 3-4.CMOS SR_Setting [0=0x0]
dm-0010.log:22124:B1B3F> LiveViewMg:ff1713b0:9b:01: 1-13.SR_2ndFrame_Setting
dm-0010.log:22270:B9C14> LiveViewMg:ff171090:9b:01: TG-SetPsave[2-6]Off 4 553648112
dm-0010.log:22390:BCA3D> LiveViewMg:ff171108:9b:01: TG-ResetPsave[2-6]On 4 553648112
dm-0010.log:22391:BCA6B> LiveViewMg:ff171728:9b:01: 2-6.AFE Standby
dm-0010.log:22396:BCB2D> LiveViewMg:ff170be0:9b:01: 3-4.CMOS SR_Setting [0=0x0]

Andy600

Edited my post because the first image was with movie record disabled ::). See the second image.

The scan says 'seems to work' for channels 2-6, 8, 10-13, 19-22 and 24-29.

Logging still freezes with LV off. Where do I set the interval?
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

a1ex

The "seems to work" only looks at whether the tested channel is locked by some other code (usually Canon code) or not. One may assume Canon code would always lock the channels they use, and unlock them when they no longer need them, but take it with a grain of salt.

The green color on channel 2 (which you have reused for raw capture) means that channel is transferring data. I don't think it's a good idea to use it, even if it appears to work at first sight. To see the activity in nearly real-time, press and hold the up or down key in the EDMAC screen (which won't change the current selection, but will cause the menu to redraw faster). Whenever there's green on any of the channels, even for a very short time, that means "stay away from it".

For LOG_INTERVAL:

Quote from: dfort on February 08, 2017, 05:28:39 AM
I don't know much about coding or reverse engineering or playing the violin but one valuable lesson I learned from dmilligan is to look at the code.

masc

I can confirm the results of @reddeercity from here on my 5D2.

This time it even works without frame rate override for me @25fps. mlv_lite 1880x1056@10/12bit, mlv_rec+mlv_snd 1856x1044@10/12bit+audio works like a charme (both non-crop). Yeah. :)

When not recording the liveview was relativly slow, maybe around 2fps and a "BUSY" was written in the corner left below of the screen and in LCD display. Using the standard nightly this is more fluently... But when recording all is fine again (okay... there are nearly no ML elements on the screen...)
5D3.113 | EOSM.202

ilia3101

@dfort Channel 0x10 does not work without fps override on 5D2, retested it with the same code 0x02 was working on. Maybe I'll have to go searching for one that doesn't have the stutter 0x02 and 0x01 has.
0x02 is best on 5D2 as of this moment.

BTW what will the process of getting crop mode not broken again be like?


... I'll try the edmac module

Update:


@andy600 channel 1 and 2 flash green sometimes, 0 is always green. 4,5,6 are always grey.  (replying to post below) Nope, only 0x05 is always grey. @a1ex but 0x02 works so well despite green :( what to do...

Are grey channels the ones to try?

Andy600

Quote from: a1ex on December 10, 2017, 01:30:30 PM
... Whenever there's green on any of the channels, even for a very short time, that means "stay away from it".

Got it. 0x02 flashes green but 0x01 doesn't. I'm using 0x01 on the 50D so I assume it's safe!?

@dfort this needs checking on the 5D2 with the EDMAC module.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

Andy600

Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

a1ex

1 is likely safe on 50D, but not on 5D2.

5 is likely used only when entering LiveView or when changing video mode, so it might be OK to reuse. The yellow ones may also be worth trying. No idea why some channels, with apparently identical configurations, give different results.

For color coding, the advice from dfort dmilligan also applies.

dfort

Just waking up here in LA LA Land and whoa--lots of reading to do.

So it looks like the 50D can use channel 0x1 and the 5D2 will go back 0x10 and will require the fps override workaround until we can find something that works better.

Where I left off last night was failing on yet another attempt at merging the work in progress for the Digic IV LVState cameras into the crop_rec_4k branch. The reason why I'm trying so hard is to get on the newest mlv_lite.

Something that I noticed this time was that the code we're testing uses RAW_LV_BUFFER_ALLOC_SIZE in place of DEFAULT_RAW_BUFFER. Check out this function in the allocate-raw-lv-buffer branch:

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
}


The only camera that looks to be coded properly in the crop_rec_4k branch is the 5D3 and it has both DEFAULT_RAW_BUFFER and CONFIG_ALLOCATE_RAW_LV_BUFFER so the above code won't work.

What about the other cameras that are functioning in the crop_rec_4k branch? Seems there are some hacks in there like using this from the 5D3:

#define DEFAULT_RAW_BUFFER_SIZE (0x4ee00000 - 0x4d600100)

It is there in the 5D3.113 disassembly. It changed somewhat in 5D3.123 because the DEFAULT_RAW_BUFFER moved to 0x48600000 [EDIT + 0X100 so that should be 0x48600100] but I can't find it or anything like it in the newest 1.3.5 firmware or in the 100D/650D/700D/EOSM disassemblies.

[EDIT2] Think I'm misunderstanding this because there are plenty of references to 0x48600000 in all of the 5D3 firmware versions.

The comments on this commit bring to light that this will work for now but we will eventually "need the correct value for resolutions higher than Canon firmware." I'm going a little off topic with this but @reddeercity -- take note.

So I thought I'd go through some links that might help understand this, like the LVState diagram for the 7D and Holy S***



The reason why I've been so active lately was because my wife has been on vacation. She returns this afternoon and if she sees these charts hanging on the walls she will for sure think I lost it.

Funny that a1ex is saying to follow my advice to look at the code, which was really dmilligan's advice to me. [EDIT] Attribution corrected.

What I feel like right now is more like this:

Quote from: High Anxiety by Mel Brooks
I got it. I got it. I got it.
[thump]
I ain't got it.


Danne


CITY-U1001

i use raw_video_10bit_12bit.2017Dec08.50D109, but now see new raw_video_10bit_12bit.2017Dec10.50D109.zip what deference  ?
50D | EFS 18-55 | last build crop_rec-3744x1080_24fps_50D-eXperimental.4.57pm.2020May06.50D109.zip

IDA_ML

Quote from: dfort on December 09, 2017, 04:16:33 PM
This morning I tried zoom mode and although the LV refresh rate was rather low I got good video at every resolution all the way up to 2520x1192 at 10bit. Don't get too excited, next time I tried it all I got was a garbled LV and corrupted frames. About the only thing consistant in zoom mode is that once you press the magnifying lens button you can't get out of that mode without restarting the camera. Still, there is a glimmer of hope there.

Dfort,

There is a way of getting out of the frozen 5x-magnification mode on the 7D without restarting the camera (see my post #1390 on page 56).  After you record a clip in that mode, just press the play button to play it back in the camera.  You get a black screen with a frame counter working.  After getting out of this black screen, (press half shutter), the camera returns to its normal state and you do not need to restart it.  It does not work always but most of the time. 

By the way, 10/12-bit recording in the 5x-magnification mode was working fine, up to 2520x1200 resolution, in the Dec. 1/2016 built that you can download from the download page of Reddeercity.  In that built, the frozen-screen issue could easily be fixed just by switching back and fort from Auto to Canon mode in the preview submenu.  After doing that, the screen would return to its normal LifeView state and would allow composing, metering and focusing for all clips to follow. As far as I remember, there was also a working raw_twk module in that built, so it was possible to playback your clips in the camera to check focus and composition for example - extremely useful!

From the practical point of view, it is very important to fix the 10/12-bit recording in the 5x-magnification mode because of its increased vertical resolution (1200p) which is unique to the 7D.  Maybe, if you compare your code with the one from the above Dec. 1/2016 built, the problem could be more easily found and fixed.  Just a suggestion.

dfort

Quote from: CITY-U1001 on December 10, 2017, 08:09:04 PM
what deference  ?

Check this:

https://bitbucket.org/daniel_fort/magic-lantern/pull-requests/16/10bit-12bit-for-lvstate-cameras/commits

You will see the latest commits. Look for the one that matches the changset on the build you are using. (7a58a90...)



Note that on Bitbucket is is truncated but that's fine. You can also open autoexec.bin in a text editor to see the information including any changes that were not committed.

Short answer, I wanted to make sure that the posted builds are using channel 0x1 for the 50D and 0x10 for the 5D2.

@IDA_ML - Thanks for reminding me about your tip. I was able to get out of 5x mode using the play button. Of course we want to get out of using workarounds like that. As far as the builds @reddeercity put up, could you do me a favor and open autoexc.bin in a text editor and report who built it? I do most of my development on rosiefort@RosieFoComputer. If it is mine you can find the source code by searching my repository for that changeset. None of this requires coding skills, it can all be done on the Bitbucket website.

Something I'm trying now is why not throw out this whole CONFIG_ALLOCATE_RAW_LV_BUFFER thing for now and instead of this:

#define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0x1000)

do this:

#define DEFAULT_RAW_BUFFER (SRM_BUFFER_SIZE - 0x1000)

It worked the same on the 7D and this would be much easier to get working in the crop_rec_4k branch. But wait, that isn't the "real" DEFAULT_RAW_BUFFER. Looking a little closer:

#ifdef CONFIG_EDMAC_RAW_SLURP
/* undefine so we don't use it by mistake */
#undef RAW_LV_EDMAC


So what if we used it on purpose? The only change needed in raw.c would be to remove that line undefining RAW_LV_EDMAC. It worked! Well, let me qualify that, it has the same issues on the 7D with the vertical resolution being limited to 976 and zoom mode doesn't work. In other words, it is working the same as before.

Hum, does that mean we have a rather large fudge factor on these buffer sizes or am I having a lucky day?

[EDIT] Or has this all been a trip down the wrong path because certainly there is a good reason to undefine RAW_LV_EDMAC. It looks like it was done a while back to fix an issue with pink frames. Of course the same thing can be done without having to define RAW_LV_EDMAC though it would take more than a one line change to raw.c.

a1ex

Quote from: dfort on December 10, 2017, 09:20:58 PM
#define DEFAULT_RAW_BUFFER (SRM_BUFFER_SIZE - 0x1000)

Do not do this. Camera bricking risk is real.

Allocate it, use a pre-allocated one, or find some unused*) memory block. Don't try random pointers hoping they will work.

*) If you decide to use this one, double-check it's really unused (test it in any camera mode you may think of - photo, movie, zoom, various FPS, while recording, external monitors, and make sure it's not going to be reused by other Canon code while you are updating it). Tools you may use: CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP, CONFIG_RSCMGR_UNUSED_SPACE_TEST, or write your own RAM analysis tools.

IDA_ML

Dfort,

I just mentioned a built that was working for me before and where I found it.  I was just trying to help.  I am sorry if I did it the wrong way.  I didn't mean to.  You know how much I appreciate your work.

dfort

Quote from: a1ex on December 10, 2017, 09:43:19 PM
Do not do this. Camera bricking risk is real.

Oops--but isn't that essentially what is going on in the allocate-raw-lv-buffer branch?

How about this for the 7D?

#define DEFAULT_RAW_BUFFER shamem_read(0xC0F26008)

This isn't supposed to work with CONFIG_EDMAC_RAW_SLURP? I can't quite follow the instructions in the comments, much less write my own RAM analysis tools.

/* hardcode Canon's raw buffer directly */
/* you can find it from lv_raw_dump, arg1 passed to dump_file:
*
* raw_buffer = get_raw_buffer()
* sprintf_maybe(filename, '%08lx.mm1', raw_buffer)
* ...
* dump_file(filename, raw_buffer, 7*something...)
*/


Quote from: IDA_ML on December 10, 2017, 10:04:44 PM
I was just trying to help.  I am sorry if I did it the wrong way.  I didn't mean to.  You know how much I appreciate your work.

Ditto from me to a1ex and everyone else participating in this.

My comments to you were similar to a1ex's to me. Instead of giving you the answer I'm trying to show you how to find the answer. Like the old proverb, "Give a man a fish and he eats for a day, teach a man to fish and he'll sit in a boat all day drinking beer."

Ok--here's the fish:

Magic Lantern Nightly.2016Dec01.5D2212
Camera   : 5D2
Firmware : 212
Changeset: b3dfbe7194f3 (x-perimental) tip
Built on : 2016-12-01 22:53:11 by rosiefort@RosieFoComputer
-e


Here is that commit in Bitbucket. if you cloned my repository this is how do it on your local copy using Mercurial:

hg log -v -r b3dfbe7194f3
changeset:   14629:b3dfbe7194f3
branch:      x-perimental
user:        Daniel Fort <[email protected]>
date:        Thu Dec 01 14:19:54 2016 -0800
files:       src/raw.c
description:
added note about PREFERRED_RAW_TYPE 18 for EOSM


You can get to that changeset by doing this:

hg update -r b3dfbe7194f3

I just tried that version on the 7D and LV doesn't get garbled up like in the latest experiments but the 5x issue is still there and the MLV files aren't working properly. My understanding is that it needs CONFIG_EDMAC_RAW_SLURP and this old version doesn't have it defined on the Digic IV LVState cameras. Back when 10bit/12bit was a new thing I was posting builds for people who couldn't compile but eventually stopped doing that when the Experiments page went up. Only the cameras ready for testing are on that page. Consider the work we're doing here pre-Alpha so you should be ready to dive into this much deeper than the casual user.

[EDIT] Just a reminder, we're all here to learn and share. Well, at least some of us are.

a1ex

Quote from: dfort on December 10, 2017, 11:16:24 PM
Oops--but isn't that essentially what is going on in the allocate-raw-lv-buffer branch?

Nope - https://en.wikipedia.org/wiki/C_dynamic_memory_allocation

RAW_LV_BUFFER_ALLOC_SIZE gets passed to fio_malloc; this returns a pointer to the allocated buffer, which is then stored in raw_allocated_lv_buffer (and used to save the LiveView frame there). The same happens in crop_rec_4k, with some additional bounds checking (which is only valid on 5D3 - the other models use dummy values just to compile).

DEFAULT_RAW_BUFFER is used as a pointer to some valid raw buffer (allocated by Canon code). On recent models (60D and newer), it is allocated when entering LiveView (evfActive), but that pointer is no longer valid when leaving LiveView (it's still there, but stale); on older models I believe it's allocated on request (by whatever code gets triggered by lv_save_raw) edit: it's also allocated when entering LiveView! edit2: false alarm, I forgot photo raw overlays enabled during the test!

5D3 1.2.3 (it appears to allocate 0x1cae000 bytes; MEM1 is the raw buffer we are looking for):

79152>        Evf:ff16b0dc:a9:03: [2] Flicker Address[0x4d318000][0x52518000]
791E9>        Evf:000aef04:00:00: *** lv_raw_buf(0x0, 0x0, 0x94897c, 0xc, 0x4d318000, 0x52518000, 0x1cae000), from ff1650d4
79200>        Evf:ff16b334:a9:03: Mem1 Address[0x4d31a000][0]


500D (full log):

1B512> LiveViewAn:ff1f6224:9a:07: [00000000:043A8818] lvaStart
...
1B944> LiveViewMg:00092b38:00:00: [00000000:043A8818] *** LVState: (1) --20--> (1)          ff0e5424 (x=869970 z=4099b360 t=1)
1B9B4> LiveViewMg:ff0e5470:98:03: [00000000:043A8818] HPCopyAsync pvParam:0x4099b360 -copy-> Lucky:0x43fd4420
1BA24> LiveViewMg:ff0de974:9b:03: [00000000:043A8818] GetResource 0x1000 (0xF07/0x1F07)
1BB16> LiveViewMg:ff1f8e28:99:02: [00869A28:00000000] SetFlickerPassParameter
...
(after a while; LiveView working normally without raw for a few seconds)
...
42F97>   run_test:00059408:00:00: [00869A28:00000000] *** call lv_save_raw ***
43011>   run_test:00093268:00:00: [00869A28:00000000] *** TryPostEvent(LiveViewMgr, 0x9, 0x1, 0x200), from ff032728
430BD> LiveViewMg:00092b38:00:00: [00869A28:00000000] *** LVState: (2) --9--> (2)          ff0e56ec (x=869970 z=1 t=200)
43126> LiveViewMg:ff0e5738:98:16: [00869A28:00000000] Set Debug Flag 0x000006A1(0x08200)
...
7FB00> LiveViewMg:ff1fb03c:99:02: [00869A28:00000000] StopQuarkPass
7FB5F> LiveViewMg:ff1f5a94:98:02: [00869A28:463390A4] GetEngineResource SUCCESS Res:4, Free:fffffffc


The numbers in brackets are (added this to my_DebugMsg to print the possible raw buffer address on every debug message):

    len += snprintf(buf+len, buf_size-len, "[%08X:%08X] ", MEM(0x15CB0), MEM(MEM(0x15CB0) + 0x328));


Addresses coming from:

DebugMsg(153, 4, "StartPass_x1 CrawAddr : %lx / KindOfCraw : %d", *(v15CB0 + 0x328), *(v15CB0 + 0x32C));
BC24B> LiveViewMg:ff1f7190:99:04: [00869A7C:463390A4] StartPass_x1 CrawAddr : 463390a4 / KindOfCraw : 0


so DEFAULT_RAW_BUFFER on 500D would be MEM(MEM(0x15CB0) + 0x328) = MEM(MEM(0x15CA4 + 0xC) + 0x328).
7D: MEM(MEM(0x17BBC+0xC) + 0x338), not tested.
(addresses are good, but they are only valid with lv_save_raw)

BTW - that "Debug Flag" from the 500D log is actually the LiveView RAW mode in Canon firmware (a feature they have used for debugging). That should explain why the x5/x10 modes in very old models are broken (pink previews, unusable x10 etc), or why the LV raw buffer on 1100D is reused for something else (as this camera has very little RAM).





Back to your question.

Pointers are memory locations; they are not interchangeable with buffer sizes (even if the C compiler may accept this). The reason it might happened to work (sort of) is the large value of SRM_BUFFER_SIZE - it points somewhere way above the DryOS core, so if it screws up things, it might do so in some non-obvious way (remember those obvious bugs from 5D3.134).

With shamem_read(0xC0F26008), this reads the address previously configured on EDMAC channel 0x10, by some existing code. Without CONFIG_EDMAC_RAW_SLURP, that's Canon code enabled by lv_save_raw; they have configured that channel with whatever buffer they have allocated for the LV raw image. The point of the new method is to bypass Canon code so we can have full control over it (such as, specify a different "raw type" or - in our case - a lower EDMAC transfer size for 10/12-bit), but since we are not going to call lv_save_raw, there will be no Canon code to allocate a raw buffer for us. So that won't work - you'll get some old value and the results are unpredictable.

Why do you want to change it? The only valid reason I can see would be to avoid the BUSY screen - in this case, just allocate as much as you need. Find the largest frame size you want to use (usually that's the raw resolution in 5x zoom) and allocate a buffer large enough for that (but not much larger). In this case, the memory backend will see no reason to use SRM buffers (which may print the BUSY message while they are allocated).




BTW, what's that -e doing there? That may indicate yet another bug in the Makefiles (a similar one was on Mac when generating module READMEs). This didn't help locating it:

grep -nr -- " -e" Mak* */Mak* */*/Mak*





P.S. 60D EvfState (compare to 7D's LVState):

Andy600

Quote from: a1ex on December 10, 2017, 11:00:34 AM
Does it help if you increase LOG_INTERVAL?

Nope. Tried 500ms, 1sec, 2sec, 5sec intervals with LV on/off, movie mode enabled/disabled etc and it still freezes.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

dariSSight

Quote from: reddeercity on December 10, 2017, 08:40:50 AM
I can confirm with @Ilia3101 on 5D2 in 1:1 non crop mode with mlv_lite & mlv full+audio ,
I can record 10 , 12 , 14 bit with out any frame corruption or out of sync Lv preview.
I downloaded the source code , changed write channel from 0x01 to 0x02 in edmac-memcpy.c  , compiled it locally in my VM.
Tested 1856x928 , 1872x936 , 1880x1056 , 1880x1016 , 1880x1128 , 1880x1248 ,  23.976 with frame over ride to exact in Auto Preview with mlv_lite
Pressed the half shutter while recording to get actuate framing with out issue , in 10 , 12bit (14bit where short 200 frame captures)

In mlv full with audio I tested 1856x928,  1856x1044 , 1856x1114 , 1856x1238 , 1856x1248 ,  23.976 with frame over ride to exact in Auto Preview ,
also pressed the half shutter while recording to get actuate framing with out issue , in 10 , 12bit (14bit where short 200 frame captures)


3x Crop mode is broken , it seems to keep the first frame it see as a alternating frame while the other frame has movement so
like frame #1 is frozen and frame #2 has normal movement and keeps repeating that pattern but frame #1 is not broken -- as in
artifacts or shearing with pink frame just frozen . I tested mlv_lite 2152x1072 & Full mlv + audio 2144x1074

*Note* Full MLV +Audio : audio was sync and was perfect , not problems.

My Camera setting and build information
magic.cfg
# Magic Lantern Nightly.2017Dec10.5D2212 (ee95e8825183+ (raw_video_10bit_12bit_LVState-wip) tip)
# Built on 2017-12-10 03:33:12 UTC by ml@ml-pc
# Configuration saved on 2017/12/10 00:17:36
beta.warn = 10
menu.first = -4
movie.log = 1
rec.notify = 0
enable-liveview = 2
fps.preset = 1
fps.override.idx = 32
fps.override = 1
battery.drain.rate.rev = 69
hist.log = 0
spotmeter.draw = 0
zebra.draw = 0
disp.mode.x = 149



mlv_lite.cfg
# Config file for module mlv_lite (MLV_LITE.MO)

raw.video.enabled = 1
raw.res_x_fine = -40
raw.write.speed = 6399
raw.warm.up = 2
raw.bppi = 0


mlv_rec.cfg
# Config file for module mlv_rec (MLV_REC.MO)

mlv.video.enabled = 1
mlv.res.x.fine = 64
mlv.bpp = 0
mlv.write_speed = 6699
mlv.display_rec_info = 2
mlv.buffer_fill_method = 0


mlv_snd.cfg
# Config file for module mlv_snd (MLV_SND.MO) mlv.snd.enabled = 1

This code looks promising for the 3.5/UHD development with custom buffers , I'll see if I can implement this in to my source code.

Edit: if anyone that can't compile and what to try out  1:1 10 & 12bit raw video with mlv_lite & full mlv+audio I uploaded to my bitbucket downloads magiclantern-10_12bit_broken_3xcrop_mode_2017Dec10.5D2212.zip

Redeercity Thanks for the testing Build, Its a big step toward at least a 12bit build. I did a quick test with 12bit setting and I will be dong some more test during this week. How do I use your setting above, is it a past and copy trick?

Test 1-with Stabilization filter
"https://player.vimeo.com/video/246759604"
Test 1-without Stabilization filter
"https://player.vimeo.com/video/246758398"
Canon 5D Mark II

Andy600

@dariSSight read the last few posts and do not use any 5D2 build that uses EDMAC channels 0x01 or 0x02 for raw recording!!

More research needs to be done.

50D testers - the 50D builds using EDMAC 0x01 should be ok.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

a1ex

Solved lock-ups in edmac.mo and polished it a bit - changes on the "edmac" branch. Merges cleanly into raw_video_10bit_12bit, if you prefer to try it there.

PR open.

Andy600

Quote from: a1ex on December 11, 2017, 01:36:51 PM
Solved lock-ups in edmac.mo and polished it a bit - changes on the "edmac" branch. Merges cleanly into raw_video_10bit_12bit, if you prefer to try it there.

PR open.

Working now :)

Not sure what you need from this but I ran the EDMAC test until it finished and also enabled logging. Uploaded the log files here.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

a1ex

Quote from: Andy600 on December 11, 2017, 04:03:39 PM
Not sure what you need from this but I ran the EDMAC test until it finished and also enabled logging. Uploaded the log files here.

Looks fine.

Try logging at 50us (or 100us or more if it freezes the image or has other problems) a few scenarios in LiveView:
- without raw video and without photo raw overlays enabled (e.g. global draw off, no other modules loaded)
- with raw video enabled, old method (run it on top of regular nightly or raw_video_10bit_12bit)
- with raw video enabled, new method (on top of dfort's modified version)

Also, for my own curiosity: log a still photo, short exposure, outside LiveView, with 500us (or 1 ms if that doesn't cover the entire process). Look at the blue LED to see when it logs and when it stops.

Take a look at the EDMAC connections screen as well (Show EDMAC channels, scroll to the right).