Danne's crop_rec_4k, 5DIII

Started by Danne, November 09, 2018, 05:11:37 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ilia3101

Quote from: Danne on January 16, 2020, 06:55:31 AM
Future, modular? I rearranged and modified to be able to just start the camera and get on using it. It's just another open source project.

Well your branch is clearly the most advanced and bug free right now, so it is the future. When referring to 'future' I meant: would a1ex want to merge all of these changes back in to the main source tree? I imagine the user interface changes (module aspect) are a bit too drastic (for exmaple some users don't want any video features), but the internal code changes are of course great.

Quote from: Danne on January 16, 2020, 06:55:31 AM
I rearranged and modified to be able to just start the camera and get on using it. It's just another open source project.

It is great and very usable, I really like the new video tab. I just want to know which modules are enabvled by default now... (and to get module screen back if I can change your mind ;))

I remember on my 5D2, loading the smallest amount of modules would increase recording times. I just think it's best to let users disable whatever modules they want, but I am not against having some modules load by default like you have done.

Quote from: Danne on January 16, 2020, 06:55:31 AM
Code is there so you can build your own tweaks if there's something you're missing but since you didn't even find the crop mode sub menu in the last build at least enjoy the oppurtunity to lower the bitdepths again ;).

Yes thanks :D

Quote from: Danne on January 16, 2020, 06:55:31 AM
It's not like the modules are gone. They are simply autoenabled. Is there a module you're missing?

Nothing I'm missing, but I want to see what's enabled and disable what I don't need. I just think it's better for module screen to stay, what if someone wants to write a new module, it's useful for them to toggle it on and off easily.

I only want to suggest improvements, sorry if anything I say sounded rude.

Danne

Nothing rude at all. I just answered :). I welcome feedback.

These modules are default:
mlv_lite \
mlv_play \
mlv_snd \
dual_iso \
silent \
lua \
crop_rec \
file_man \
ettr \

You can add any additional module by simply putting it in the module folder on your card and it should appear the normal way.
You can also look for this line in module.c in src folder:
char *core_modules[] = {"mlv_lite", "crop_rec", "mlv_play", "mlv_snd", "sd_uhs", "lua", "file_man", "dual_iso", "silent"};
And erase:
char *core_modules[] = {};
Or erase all code related to core_modules and it should be back to normal. Didn´t dig in to hard on this. It´s mostly Jip-Hops code parts in this case and works really well.

About bugs I created a couple of pull requests. All the rest is small quirk fixes here and there, nothing big really. A1ex also developed a refined crop_rec code for the 700D which might be the new standard in the future. Who can tell really?

ilia3101

Ah good to know where that array is.

Also do you knokw why mlv_rec.mo stops working with crop rec enabled? I would be interested in trying to fix that (unless it's a really huge task), as I want to try card spanning.

Danne

No idea really.
By the way. You should port card spanning to mlv_lite ;)

timbytheriver

Quote from: Danne on January 17, 2020, 11:33:49 AM
By the way. You should port card spanning to mlv_lite ;)
+1 :)

I'm looking into this as well! I see the code in sd_uhs.c for enabling it in 5D3 (untested), but I assume additional code has to be ported into mlv_lite.

In which module does the code that needs to be ported live now?

5D3 1.1.3
5D2 2.1.2

ilia3101

Quote from: Danne on January 17, 2020, 11:33:49 AM
No idea really.

😢

Quote from: Danne on January 17, 2020, 11:33:49 AM
By the way. You should port card spanning to mlv_lite ;)

I like the sound of this too. I just looked at mlv_rec.c, and it seems not too complicated (an extra thread and loads of if statements).

But I need to gain some understanding of magic lantern code first. It's not as simple as c library and pthreads :'(

What branch would be the best starting point for this modification? Unified, crop_rec_4k or something else?

Danne

I would work in this branch directly. I see no reason no too. I ported global draw off a while ago. Not as hard as card spanning though but as you say. Not impossible to understand but It's a bit over my head.

ilia3101

Quote from: Danne on January 17, 2020, 01:07:42 PM
I would work in this branch directly. I see no reason no too.
Yeah ok. I cloned crop_rec_4k_mlv_snd_isogain_1x3_presets, this is the main one right now?

Quote from: Danne on January 17, 2020, 01:07:42 PM
I ported global draw off a while ago. Not as hard as card spanning though but as you say. Not impossible to understand but It's a bit over my head.
I am not sure where to start really. I see in mlv_lite theres loads of "NO_THREAD_SAFETY_ANALYSIS" which is a tiny bit concerning. Currently trying to compare how both modules do writing, it seems to be making a little bit of sense, but there's no clear comments like "this line writes the frame", so it's a bit difficult.

Are the FIO_* functions used for writing actual big frame data? Or are they just for headers? I can't tell what they are doing... just 'jobs' according to variable names.

gravitatemediagroup

has anyone else experienced blacked out playback as if something went wrong with recording, but when loaded into MLVApp the image is there?  I've been noticing this the past few builds, I've tested and changed various settings/resolutions to see if I had accidently turned something off, but every shot comes back blank.  The liveview before shooting is there, just no playback.

sorry if this has been discussed already, i'm short on time so I just jumped to the end of the thread to ask. :) 

Danne


ilia3101

@Danne how often do you update mlv_lite.c? I hope we do not make changes at the same time that will be difficult to merge.

Danne

I only do minor changes. Did a small change today. Just keep on with your stuff. WHen ready I can merge it into mine branch.
By the way, where´s the branch you are working on?

ilia3101

I hg cloned crop_rec_4k_mlv_snd_isogain_1x3_presets yesterday - and am editing mlv_lite.c in there. Same branch as you?

Danne

Yes, same. Could you link your repo so I can follow?

ilia3101

Hmm I don't have it on bitbucket, I just typed "hg clone https://bitbucket.org/Dannephoto/magic-lantern -b crop_rec_4k_mlv_snd_isogain_1x3_presets" and started making changes. Should I make a branch of my own to my bitbucket account? How do I do that?

So far, I have been saving versions by copying the file, not through commits because I don't know how to use mercurial, however I can put those versions in to commits once I get the mercurial stuff set up properly.

ilia3101

I'm guessing maximum number of chunks of an MLV is 101? as you can have only one .MLV, and 100x of .M00-.M99

ilia3101

It's actually really difficult to adapt mlv_lite for spanning. I will try again with a different approach, it's a bit of a mess this first attempt, I just tried to copy most of the way mlv_rec does it.

In mlv_rec writing loop is so much simpler, here it is tangled in to everything, so it's difficult to have two running at the same time. I wish we could have mlv_rec working with crop_rec.

Danne

Hm, keeping mlv rec is hard to justify. No lossless recording if I recall correctly? Only reason to hold on to it would be if both lossless and card spanning were working but ultimately if you manage to get it working on mlv_lite personally I would think it's the better way.

ilia3101

Quote from: Danne on January 18, 2020, 07:16:02 PM
Hm, keeping mlv rec is hard to justify. No lossless recording if I recall correctly? Only reason to hold on to it would be if both lossless and card spanning were working but ultimately if you manage to get it working on mlv_lite personally I would think it's the better way.

I am trying again on mlv_lite, this time without copying how mlv_rec does it, as it's just too different.

Also I didn't realise mlv_rec didn't have compression, I always thought it was the more "advanced one" :D That's what I felt from using the 5D2 anyway :D But I guess I was wrong :-\

I think one advantage to mlv_rec is that it writes EXPO blocks for each exposure adjustment during recording, while mlv_lite does not, is that correct? Or is this also outdated information?

Danne

Yeah, mlv_lite is stripped for maximizing speed. Originally dmilligan started out building this module.

Stousen

Hi, I love the anamorphic mode, and i do not mind that it is squeezed in live view, and its perfect to be able to frame The desqueezed view before recording.
But i have one question that i rly havent found clearity to yet.
Even tho the live view is squeezed, is it possible to move the center position so that it matches the center better?

I made a video including external monitor to show what i mean.
It would be very very useful, (atleast for me;) ) if it was possible to match the squeezed views center point to the live view center point. In laymen terms, move the image up;)

https://vimeo.com/385713397/4aed6ecab1

Is this complicated / goes much deeper than what I may think?

Thanks!

Kind regards
//Chris

ilia3101

I am almost done with card spanning, I have a very simple solution. just need to sort out one final thing: sharing the "slots" thing between two threads. Need to figure out what it is (I think it's a queue) and how it works, then how to share it. Going to leave this for tommorow.

Quote from: Danne on January 18, 2020, 07:44:24 PM
Yeah, mlv_lite is stripped for maximizing speed. Originally dmilligan started out building this module.

So it would be nice to get mlv_rec working again and add compression support ;)

Danne

Hehe, well. Who knows what tomorrow brings. Nice to hear about your progress on card spanning!

garry23

I thought some of you videographers :) ;) may be interested to know that this 4mm fisheye lens us now available in an m mount, and it's cheap as chips.

https://www.venuslens.net/product/laowa-4mm-f-2-8-mft/

ilia3101

Should I add another struct semaphore * for protecting the slots array / writing queue when accessing it from two threads? Or should I extend the use of settings_sem to protect that?

BTW I am not adding any of this "guarded by" stuff to anything I add, as I don't know how to use it correctly. But as I understand that only affects static analysis, not running the code.

Also why does the code sometimes use '0' instead of NULL for pointers?