crop_rec on steroids: 3K, 4K, 1080p48, full-resolution LiveView

Started by a1ex, April 01, 2017, 11:15:41 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Danne


mothaibaphoto

Same s**t:
ML ASSERT:
0
at mlv_lite.c:2723 (compress_task), task compress_task
lv:1 mode:3

compress_task stack: 1ae538 [1ae5c0-1ad5c0]
0x0006A030 @ ae1174:1ae568
0x00069868 @ 6a09c:1ae538

Magic Lantern version : Nightly.2018Oct09.5D3113
Mercurial changeset   : 41153b1177ce+ (crop_rec_4k_mlv_snd) tip
Built on 2018-10-09 14:52:06 UTC by VOLD@VOLDMONSTER-II.
Free Memory  : 211K + 2983K

By the way, your code example with error: 1048 instead of 1080 in preset. But your repo code is correct.

a1ex

To minimize further confusion, I've decided to move Danne's experiments to a new topic.

As long as these builds contain mislabeled ISO settings, I am not going to support them, sorry.

Danne

 I will erase the iso stuff when I get the time. They have no valid reason for being in there. Focus in this build should be 1x3 settings and playing with analog gain registers getting most out of the settings. Accepted build?
Bugs are still valid though. Mv720p stuck preview and lack of framing preview while using hdr or having adtg_gui module enabled.


Danne

Would like to understand more about shutter blanking and see if we can fix a bug. In 100D when including following in consts.h:
#define FRAME_SHUTTER_BLANKING_ZOOM   (*(uint16_t*)0x41697784) // ADTG register 805e
#define FRAME_SHUTTER_BLANKING_NOZOOM (*(uint16_t*)0x41697ac0) // ADTG register 8060
#define FRAME_SHUTTER_BLANKING_READ   (lv_dispsize > 1 ? FRAME_SHUTTER_BLANKING_NOZOOM : FRAME_SHUTTER_BLANKING_ZOOM)
#define FRAME_SHUTTER_BLANKING_WRITE  (lv_dispsize > 1 ? &FRAME_SHUTTER_BLANKING_ZOOM : &FRAME_SHUTTER_BLANKING_NOZOOM)

I can compile and use a build but shutter is always set to 1/24 on overlay screen. Does it indicate incorrect definitions or are there more places in code to defoine maybe? Thanks.

a1ex

Yeah, these definitions appear to be dynamic on some models (on 700D it's also wrong). Back then, I've found them in some property blocks, so at least I should be able to find a fixed pointer to these addresses. Unable to look into it right now, sorry :(

Danne

Ok, thanks. I think I found the correct ones with adtg_gui when in photo mode! Seems to be working now.
#define FRAME_SHUTTER_BLANKING_ZOOM   (*(uint16_t*)0x41697bc4) // ADTG register 805f
#define FRAME_SHUTTER_BLANKING_NOZOOM (*(uint16_t*)0x41697bc8) // ADTG register 8061

a1ex

Yes, these are valid for you (or for your current startup sequence, or whatever causes these addresses to change), but they may be not be valid for all other 100D users. The previous ones were found in the same way.

Danne


leandroprz

I tested the latest crop module last night on my 6D and I'm getting 2/3 of the image with a magenta color:



I used mlv_lite and mlv_rec both with default settings. Both give the same results.

Any idea what could be happening?

a1ex

Best guess: some sort of misconfiguration for ADTG powersaving registers.

Please define "latest crop module", mention the settings used for crop_rec (including resolution and frame rate in Canon menu) and the number of affected lines (the low-resolution screenshot doesn't help much).

leandroprz

Quote from: a1ex on November 27, 2018, 09:07:54 AM
Best guess: some sort of misconfiguration for ADTG powersaving registers.

Please define "latest crop module", mention the settings used for crop_rec (including resolution and frame rate in Canon menu) and the number of affected lines (the low-resolution screenshot doesn't help much).

I'm using magiclantern-crop_rec_4k.2018Jul22.6D116.

  • Settings for crop_rec: default, I touched nothing
  • Canon menu settings: 1280x720 @ 50fps, Low comp (ALL-I)
  • Number of affected lines: 540px
Here's the full-res image: https://i.imgur.com/ZbvYcPq.png

a1ex


leandroprz

Quote from: a1ex on November 29, 2018, 12:05:24 AM
Did this work any better in previous builds? If yes, can you find the last good build?

https://builds.magiclantern.fm/jenkins/view/Experiments/job/crop_rec_4k/

This is the first time I'm using it. I'll test previous builds and see how that goes. Will report back after testing.

leandroprz

I tested a few builds and went back to the first build that supports the 6D (magiclantern-crop_rec_4k.2018Mar10.6D116.zip) and even that one doesn't work properly.

I also reseted the camera to factory settings before testing.

Danne

Quote from: Danne on November 17, 2018, 05:03:37 PM
Mv720p stuck preview and lack of framing preview while using hdr or having adtg_gui module enabled.
I assume this didn´t go unnoticed. Anyway. Would be great to get some insights to why mv720p and crop_rec gets stuck when trying to get out of x10 mode. Sorry my nagging here but 1920x1080 48fps setting is golden.

On the bugside let´s not forget this:
https://www.magiclantern.fm/forum/index.php?topic=22963.msg208129#msg208129

I also noticed that dualiso module will report the diso metadata into files even if dualiso isn´t set. Bug.

leozan

Latest Nightly Build: 2018-07-03
Experim. Latest Build (2018-07-22)

what happen's ?!? afraid....

goldenchild9to5

@leozan The lastest build is good to go works perfectly on my 5D III. 

leozan

to read lasts back post for nightly and more in exp.  , seem not be all perfect.
but later many updates , now are months of silence.
I think we are in the near end or? :(

Danne

changed another place in power time registers:
-        int fps_timer_b = (shamem_read(0xC0F06014) & 0xFFFF) + 1;
+        int fps_timer_b = (shamem_read(0xC0F06014) & 0xFFFF);


When fps override set this is giving corruption(pulsating minor stripes) to footage with certain presets.
commit:
https://bitbucket.org/Dannephoto/magic-lantern/commits/aa687c72d837ce56511e566db19941d7c5a18522

Is it needed? Not sure what it´s for so erased it for the time being.

dfort

Quote from: a1ex on August 29, 2018, 04:08:39 PM
Alright, please find the first proof of concept for crop_rec with arbitrary resolutions. 700D only; won't work on any other model yet.

Now that I've got crop_rec_4k working again on my camera (this commit broke it and this was the solution for my 700D) I thought I'd try this out. Didn't get very far, but it looks promising.

Quote from: a1ex on August 29, 2018, 04:08:39 PM
Beware: might be very buggy. After changing settings, press MENU twice to refresh. Have fun.

Yes it is! First few times I used it I got a warning, "Card's write protect switch is set to lock" and had to reformat the card to get rid of it. Tried to follow Reply #1839 from @theBilalFakhouri but somehow wasn't getting the same results.

Yeah, I know--not much of a report.

theBilalFakhouri

An easy trick how to fix scrambled LiveView in higher horizontal resolutions :

"For real-time preview in higher resolution mods. Do you mean how to solve the scrambled broken LiveView?

Using new crop_rec I can get 1x1 mode in mv1080 without getting into x5 mode. Simply I can select 1x1 Binning and The sensor will be cropped to 1x1 1736x1160 .

The real-time preview isn't broken yet but If I increased the horizontal resolution to 2520 it will break, to fix it Now I can press magnification button and get into x5 mode and the LiveView will be working again.

Okay so we can get benefit from this trick to lock the registers between this two mods and find the right ones by trial and error and apply it in mv1080 then if the LiveView worked like x5 mode this mean we found the right ones and now we can play with them to fix LiveView in higher horizontal resolutions."

Levas

There is something weird going on with lossless and or crop_rec recording. (At leats on 6d that is  :P )
With the higher resolution crop modes I always felt that I got less recording time then expected considering frames size and buffer memory.
But since we have lossless compression, frame size varies so I thought it was caused by the variation in compression.

But it still bothered me, so did some testing.
I have a crop mode setting which records in 5464x3072 at 5.6 FPS.
This resolution and frame rate setting is very heavy, lots of data, so the SD card doesn't have much time to get on speed and I think we're actually measuring used buffer size with this setting.
The buffer on the 6d is 255MB.

When I use plain 14 bit recording I get a video file of 235MB
When I use plain 10 bit recording I get a video file of 189MB
When I use lossless 14 bit recording I get a video file of 119MB

The only one I can explain with 255 buffer size in mind is plain 14 bit recording.
The 10 bit and 14 bit lossless video files are much smaller then buffer size, the 14 bit lossless is actually 2 times smaller then the buffer size ??? How can it be ?

The 14 bit file size of 232MB makes sense:
One frame in plain 14 bit is about 29MB, 255MB buffer divided by 29 = 8.8, since you want whole frames, this is rounded to 8 frames. 8 times 29MB = 232 MB which is exactly my video file size I get with normal 14 bit recording  :D

The 10 bit file size of 189 is weird.
One 10 bit frame is about 21MB, 255MB buffer divided by 21 = 12 whole frames. 12 x 21MB = 252MB. But I get only 189MB ???

The 14 bit lossless is even more weird.
I extracted the MLV file with MLV dump to DNG files and let it recompress the frames. Frame size appears to be around 18MB. 255 buffer memory divided by 18MB = 14 whole frames and 252MB in video size. But I get only 119MB, that's half of what I expected ???

Another weird thing is that MLV_dump doesn't seem to extract all DNG's out of the file.
14 bit recording file of 232MB gives 6 DNG's of 29.4MB each and a audio file less then 0.5MB, which is one frame less then expected according to filesize.
10 bit recording file of 189MB gives 7 DNG's of 21MB each and a audio file less then 0.5MB, which are two frames less then expected according to filesize.
14 bit lossless file of 119MB gives 4 DNG's of 18.2MB each and a audio file less then 0.5MB, which are two frames less then expected according to filesize.

Conclusion:

With 14 bit lossless compression I get 4 frames, where I expect about 14 frames (according to buffer memory and frame size)

P.S. this is all done with te experimental 4K build off 22 June 2018 from the downloads page and a customised crop_rec module.

Levas

Starting to wonder, how are frames written to the buffer when lossless compression is used?
I would expect that frames are stored compressed in the buffer, but I'm in doubt if that really is the case? Are frames in the buffer memory compressed or uncompressed when lossless recording is selected ?