Messages

Any way to disable logging?

This version of raw_rec is slower than previous.

results for 650D, 23.976 fps, GD off:

Resolution               First Implementation              This version
1568 x 656                62 s                                           50 s
1600 x 672                32 s                                           27 s
1728 x 720                12 s                                           10 s

Just found the source.
Didn't noticed, the branch can have multiple heads:

Have you tried PM'ing pravdomil and/or a.d.?

Just did it. Hope my sucky english won't irritate those helluva guys )

Yes, thank you. I am aware of these builds. Now we need the source code.

There was a vital feature back in the days in pravdomil's and a.d.'s builds — the cropmarks while recording with Global Draw off.
It is vital for low-end cameras, because of GD needs some processing power, and switching it off while recording gives several seconds of recording until skipping frame. But it is difficult to record without proper framing. Yeah, you can just stick some tape on the LCD but... you know, we are the serious guys right? ))

Here's what i'm talkling about:

This is how it looks while recording. I remeber, i built it in july 2013 with some additional changes and used to use it until nowdays.

I have no idea, why this wasn't included in unified, but I'd like to implement this nice feature at least in my builds, because it is the only reason which not allows me to call the nightlys "production-ready".

The problem is I can't find the source for that particular changes.

Related links:
http://www.magiclantern.fm/forum/index.php?topic=5533.0
This thread is where I found this feature back in a day. It states from the beginning "mlv_rec: crop marks for GLDraw Off". It leads to the pravdomil's source:

https://bitbucket.org/pravdomil/magic-lantern-hack/
But here in the sources of raw_rec module I can't find any traces of that feature.

First link thread is closed and pravdomil says in last post: "Only two features are remaining (1880 width and  crop marks for GLDraw Off), but this is small changes so there no reason why keep this fork updated."

So what I'm asking for is: please help me to find the source code of this feature, or give me some clues on how to implement it by myself (i'm not so great at ML's structure yet, but have some basic coding skills)

UPD. Found the source here:
https://bitbucket.org/pravdomil/magic-lantern-hack/src/371d7565bcee926b4b3c50010a9fc15c41f7e0fc/modules/raw_rec/raw_rec.c?at=unified

As I can see, there is LESS aliasing and moiré when shooting RAW with the latest build, right?
And sorry for being newbie at this, but what does SRM mean?

I'm using VAF filter — I think production work is impossible in most cases without it (on low-end Canon cameras)

You can read about SRM memory interface here

...but I think I would prefer to wait until this issue is solved "in-camera" in a future nightly build...

You know, this may be never happen.
Your position is strange to say at least. While you are waiting, we are shooting some nice deep-color detailed raw footage and make some killer vids.

Just a couple random screenshots from my tests:







This is how raw footage from 650D looks now.

By the way, 720p is continious, and even a little more, say 1312x736 records on my camera till the card is full.
With the latest SRM memory interface, we've got larger buffers, and now we can shoot nice cinemascope at say 1568x656 for about a minute before skipping, which is far then enough for almost any stage shots.

PDR tool works fine and treats the focusing pixels nicely, it preserves almost all perceptible detail, because important to our eyes green channel is untouched by pink dots.

So what are you waiting for? Jump in!

Downloaded this nightly build for 6d, it worsk, but no extra seconds of MLV recording.

This might be helpful:

Also reformat card from camera for both test and see if mlv_rec allocates the 154MB before first recording. If you dont reformat you wont see it because it is already created.

So now we have SRM memory interface working with raw_rec module.
It gives us additional 2x31 MB of buffer memory for recording.
Thanks to mk11174 for finding STUBS and for Dmilligan for making changes to modules.

Some quick results at 23.976 fps:

Resolution                     Old rec. time no SRM (GD off)       New rec. time with SRM (GD on)
1568 x 656 (2.39:1)      32 s                                              53 s
1600 x 672 (2.38:1)      18 s                                              32 s
1728 x 720 (2.40:1)      7 s                                                12 s

So we have x1.7 recording time increase even with Global Draw on

Some quick tests with raw_rec for 550D at 23.976 fps:

Res.               Before               Now
1280x720      4 s                    8 s
1280x592      7 s                    14 s

So basically near the 2x rec. time increase.

But mlv_rec allocates 134 MiB — don't know, if it's new maximum for the 550d?

Stubs for 550D (tested. working)

/** ExMem **/
NSTUB(0xFF06C678,  CreateMemorySuite)
NSTUB(0xFF06c4A8,  DeleteMemorySuite)

/** SRM JobMem **/
NSTUB(0xFF028590,  SRM_AllocateMemoryResourceFor1stJob)
NSTUB(0xFF02AD5C,  SRM_FreeMemoryResourceFor1stJob)
NSTUB(0xFF06BEC8,  CreateMemoryChunk)
NSTUB(0xFF06C918,  AddMemoryChunk)

Confirmed working on 650D. Thank you, dmilligan!

Results at 23.976 fps:

Resolution                     Old rec. time no SRM (GD off)       New rec. time with SRM (GD on)
1568 x 656 (2.39:1)      32 s                                              53 s
1600 x 672 (2.38:1)      18 s                                              32 s
1728 x 720 (2.40:1)      7 s                                                12 s

So we have x1.7 recording time increase even with Global Draw on

Here Pravdomil says, "Only two features are remaining (1880 width and  crop marks for GLDraw Off)"

The thing is, Cropmarks for GLDraw Off — is the vital thing for low-end cameras, because GDraw affects the recording speed and you should turn it off, but you virtually can't record without proper framing.
This is the reason why some of the users can't use the nightly builds, since this feature not implemented (yet?)

I'd like to implement it in my own builds, but can't find the needed commit.
Can you please point me to the corresponding lines in your code, which affects this behaviour?

No, LV is using 2 of the buffers itself, that's why you only get 2 in LV.

Now it's clear. Thank you.
Dmilligan, can you please help us to adopt these changes to legacy raw_rec module?

I am asking because its speed still perceptibly higher than mlv_rec, and that matters for low end cameras.
For example, with my old raw_rec build i've got about 80 seconds of 1536x640 at 24 fps.
But with mlv_rec even with new SRM job buffers only about 50 secs.

This is because raw_rec speed hovers around 38.4 MB/s, but mlv_rec only about 37.
If we'll be able to make raw_rec to use new srm buffers, it will be a huge addition to recording times!

Yes, the 8E58 seems to be correct.
Also, now i get 4x31 MiB outside LV, but 2x31 in LV.
Don't actually understand that. Is it possible to use all 4x31 buffers for mlv recording?

Thank you, mk11174 for your findings!
I'd prefer to know about some search 'algorithms' to find the stubs by myself, but i may suppose it is not what's easy to say in two words )

Anyway, now I get the same strange results as yours on 650D:
The test from 'don't click me' shows only 1x31 Mb buffer and dimilligan's mlv_rec only reports 123MB
But mlv patch from gg3g0 still works and gives 154 Mb.

Need some clues on how to find the CreateMemoryChunk and AddMemoryChunk stubs.
(for 650d rom)

We have this:


It says NSTUB ( 0x8B7C, CreateMemorySuite) in stubs.S, but ROM disassemble starts with ff000000, so how does that make sense? I suspect RAM_OFFSET has to be take into account. A1ex says in tutorial, that it is declared in stubs.S, but it's not the case for 650d. So how do I know my ram offset for particular camera?

for the AddMemoryChunk, i can find many strings like 32(Src,bytes,Unit... , and before them i usually got this:

Does that mean, 8E58 has some relation to AddMemoryChunk start address?

Bulb timer in Shoot menu gives you up to 8 hrs exposures.

Thank you.
One more impatience question:

May I ask you to give me some help to adopt your mlv_rec patch to raw_rec.mo?
Is it possible to use SRM job memory buffers in raw_rec at all?
This module treats memory differently, and I can't figure that out by myself.

You have to define it as far as I know, look in the patch for the define, its long, or to test just comment out.

Got it. 154 MiB allocating instead of 92 on 650D.

Oh, by the way, when i enable trace write, i can't find it anywhere on the card. Nothing shows up in console either (when mlv_rec is working). How can i see the debug trace?

Ok, i've added these stubs to stubs.S, applied this patch to the mlv_rec.c and compiled.
Everything went fine, ML loaded ok, module working. But no difference at all with regular mlv_rec.mo.

Am i missing something, additional steps needed? Or may be stubs addresses wrong?

I want to find these stubs for 650D.
Is there sort of "easy way" to try that?

I mean point me please to some reading about that?

The easy way:

1. Import your footage and interprete it properly:
50 frames at 10 fps = 5 secs.


2. Create appropriate comp for your footage. You can simply drag and drop it to the new comp icon:

This new comp's length will be as it says, 5 seconds long.

3. Go to composition settings and change desired framerate

It still will be 5 secs

4. Apply twixtor and just enter 10 as "Input Frame Rate"


Now you have your composition 5 seconds long at 25 fps.
That's it. This is the proper way to use twixtor for frame rate change tasks.

Jesus christ! No. You just make comp at desired fps, but long enough. Make it 100500 seconds long if you wish and you're good to go.