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 4 Guests are viewing this topic.


QuoteI did find a bug on the EOSM that I couldn't resolve. When in zoom mode at maximum 2520x1080 resolution if you set the FPS override to "Optimize for Exact FPS" or "Low Jello, 180d" the right side of the image gets chopped off and glitches appear every few frames. Basically, a black bar on the left of the frame that can be seen on the LiveView screen if the Preview is set to Auto or Framing.
This bug, altough in my case it's on the right side (as a1ex), is there for at least 9 months, i have it in my test from April ( ). Strangely enough, it disappeared when fps was set to 15 fps ( With build from December the 19th it's not true any more, and stripe is there to stay (only in exact fps mode though).
I will test your new build tomorrow.


Quote from: a1ex on January 25, 2018, 09:33:56 AM
I have a feeling most users will prefer clean footage (without hiccups) over "perfect" 1080p resolution :D


A1ex is right.  We all would prefer perfectly clean footage without hiccups and corrupt frames and WITH SOUND in all video modes rather than the 2 missing pixels.  Upscaling from 1078 to 1080 which Resolve does automatically anyway, will hardly affect quality.

My suggestion to you is:  Please prepare a build that in your opinion works well in the above way, making sure that sound is working properly in all modes and I will test it for you.  Leave the focus pixels for the very final stage after we all make sure that everything else works fine.  Then I will perform the Pixel Scanner test again and you can make corrections to the focus pixel maps. 

Keeping in mind the latest remarkable developments on the 100D, I personally would like to see a reliable and stable build, with all functions working properly, that all 100D users can take and use with confidence on their trips and vacations.  I think that the 100D is very close to this stage of its development.   So, here is my request to all developers involved with the 100D in one way or another.  Please help Dfort complete his mission!  Thank you all in advance. 



Quote from: loknar on January 25, 2018, 11:08:59 AM my case it's on the right side...

Quote from: a1ex on January 25, 2018, 09:33:56 AM
I see the bar on the right.

Ok, don't know my left from my right -- edited my post. So yes, there is a black bar on the right like in the video @loknar posted. If you stretch the image you'll see that it isn't just a black area:

Quote from: a1ex on January 25, 2018, 09:33:56 AM
This kind of black bars with FPS override indicate the FPS_TIMER_A_MIN for EOSM is way too low ...

Thanks! Good to know what to tweak.

Quote from: a1ex on January 25, 2018, 09:33:56 AM takes a dedicated tester like IDA_ML, with lots of attention to detail, to narrow down such "subtle" issues that make the camera unusable in certain video modes.

+1 for IDA_ML


Quote from: a1ex on January 25, 2018, 09:33:56 AM
This kind of black bars with FPS override indicate the FPS_TIMER_A_MIN for EOSM is way too low (and may need fine-tuning for each video mode, as it's done on other models).

Looks like there has been some fine-tuning on the EOSM but the zoom setting probably wasn't tested at 2520x1080. The current settings work fine at 1920x1080.

#elif defined(CONFIG_EOSM)
    #define TG_FREQ_BASE 32000000
    #define FPS_TIMER_A_MIN (ZOOM ? 666 : MV1080CROP ? 532 : 520)
    #undef FPS_TIMER_B_MIN
    #define FPS_TIMER_B_MIN ( \
    RECORDING_H264 ? (MV1080CROP ? 1750 : MV720 ? 990 : 1970) \
                   : (ZOOM || MV1080CROP ? 1336 : 1970))

Fiddling with the FPS timer A in the FPS override Advanced settings, the black bar on the right completely disappears at 716 (FT +50) with the Exact FPS and Low Jello, 180d options. Should I add this to the current pull request?


Sure. That's quite a difference...

Cross-checking: the black zone starts at 2320 out of 2520 pixels, so it's 200 pixels wide. In raw.c, column_factor for EOSM is 4 (meaning: one unit in 0xC0F06800/4 covers 4 pixels horizontally). Since you had to adjust FPS timer A by 50 units, that probably means the FPS timer A has the same units as the register that controls the image capture resolution.

This column_factor is probably the number of columns read out in parallel. On 5D3, this value is 8, and the well-known vertical stripe pattern repeats every 8 pixels.


Ok, done. New build looks good on the EOSM now. Posted a new test build.


PLS!!!!!!!!!!!!!HELP ME,

I have a 5d3 fimrware 1.2.3
after instalation magiclantern-lua_fix.2018Jan20.5D3123 i dont see  crop_rec , i don't see nothig 4k.
My full resolution is 1920 :(. Why??????


You downloaded the lua_fix build, not the crop_rec_4k build. Look for this one on the experiments downloads page:


You'll find it under: "4K raw video recording; lossless compression"

[email protected]

Any suggestion is greatly appreciated:

Using 5dIII 1.2.3,  the storage card is: SanDisk Extreme Pro 128GB, 160MB/s. 

I followed the steps to use crop_rec. Downloaded and installed the Dec 2017 version.  Shot video using the steps as per the video in this forum a few pages back, and the MLV files were created.  But when I import the files into Resolve 14, all I get is noise.  I have successfully did the same procedure with the regular 5dIII 1.2.3 Dec 2017 release (not crop_rec), and everything works fine.  (Just shooting 1920x1080 24p).  Resolve imports the files and they can be edited.

My overall goal is to shoot 1920 x 1080 48p, but I have never been able to do that either using crop_rec.  Same thing, the files seem to be corrupted.  I purchased the EosHD Shooter's Guide (from, which explains a lot and is helpful.  I followed the steps there.  Same thing, the MLV files seem to be corrupt when imported into Resolve 14.

So basically, to sum up:  I have not had any success creating editable MLV files using the crop_rec release.

Any suggestions are very helpful and appreciated as to the corrupted files problem.  Must be some setting I am missing.  But no idea at this point.  Thanks in advance.


Quote from: [email protected] on February 01, 2018, 01:25:18 AM
...the MLV files seem to be corrupt when imported into Resolve 14.

You need to convert the MLV files to DNG image sequences before importing into Resolve.

Now that I had such good luck with hg bisect on another crop_rec_4k issue, I'm going to resurrect the discussion we started back in Reply #1157 Specifically:

Quote from: a1ex on September 21, 2017, 02:25:14 AM

# compile and test again, just to be sure it works
# the result should be identical to 5b6936ed7aab -
# Erwin's version before decompression and 5D3 patch
hg bisect --good

Turns out that when I followed the instructions the changeset wasn't working with FRSP lossless on the EOSM. I tracked down the problem to commit f6d95f2. Déjà vu:

Quote from: dfort on September 22, 2017, 10:39:14 PM
Found  out that if I back up all the way to the silent.c in a9c8ad4 and keeping everything else at the lastest in crop_rec_4k the FRSP lossless compression DNG issue with EOSM/700D is not present. Updating to commit f6d95f2 the issue shows up.

It should be printing out an "Out of memory" error message if there is a problem but everything seems to work fine when you are shooting pictures though no lossless DNG files are saved to the card.

I hacked together a silent.c that works with all cameras but it isn't a satisfactory solution. There's a note on the pull request to add some printf's to see where it fails. Not sure where to start with that but I'd really like to get this issue resolved properly.


Regarding printf's, you need to find out why it fails (why it takes some particular code path, what are the return values etc). Some example in pseudocode:

int x = check_this();
if (x > y)
    return 5;
    return do_that();

After adding printf's, it could look like this:

int x = check_this();
printf("check_this returned %d, expecting > %d\n", x, y);
if (x > y)
    printf("doing this\n");
    return 5;
    printf("doing that\n");
    int ret = do_that();
    printf("do_that returned %d\n", ret);
    return ret;

In particular, we need to find out why the DNGs are not saved - likely bad input data to save_dng. Was save_lossless_dng able to allocate memory? (print the input and output values: max_compressed_size and out_suite). Did the lossless compression work? What return value did you get? (it returns compressed size or negative error code). Does the raw data get recognized by save_dng as a lossless stream? (return value of is_lossless_jpeg). What's the size of the data it's trying to write to card? And so on.

If it's able to allocate memory, but for some reason, lossless_compress_raw fails, compare with your version and see what's different. Do you try to compress an image with different size? (maybe smaller? maybe some dimension is modulo some power of 2? no idea here, there may be additional hardware restrictions on certain cameras).


Hi, my English isn't good so I apologize for my mistakes.
I try to figure out how to use Crop mode 1920 50/60 3x3 in proper way.
First I switch fps in Canon menu to 50.
Second I turn on RAW video (1920x818) and Crop mode (1920 50/60 3x3).

I able to record 1920x818, but:
in my live view I can see:

but my footage looks:

It's a diffrent position.
Any advice to solve my problem?



Pushed some updates, mostly integrating previous work in one build:
- experimental mlv_snd support from ErwinH (thanks IDA_ML, Danne and dfort for identifying and squashing the bugs)
- latest Lua stuff (please try the linked tests on this build, too)
- latest memory updates for raw backend (please report back on 70D and 100D, will require compiling from source)
- various small fixes
- an experiment that lets you move the preview window around in x5 mode using the focus box

Caveat: you may lose frames if you move the focus while recording!
(nothing new, this happens in all ML builds, but now you might be tempted to move it)

@Tom_LS: from the download page:
You will generally need to use the (non-realtime) preview from the raw recording module.
Modes with higher vertical resolution will have real-time preview only for the top of the frame.

Lars Steenhoff

Great updates!
I like to test latest manual lens updates with the 4k branch, 
would the way to test them just to import manual lens branch into 4k crop,  now that Lua fixes are in place in the 4k branch?


That's next - I already have some local changes to fix the issues there. I just wanted to integrate the refactors first - there were some changes on the lua_fix branch that touched many parts of the code (refactors to get consistent behavior among all camera models).


Quote from: a1ex on February 01, 2018, 10:02:41 AM need to find out why it fails (why it takes some particular code path, what are the return values etc).

Looks like you added another check, Silent pictures: check for lossless compression errors. The message flashes by pretty quickly so I shot a video of the screen to make sure I'm reporting the error message properly:

Lossless compression error: -2


Semaphore timeout (in other words, the encoder did not run).

Now compare with your version and see what parameters you have different: maybe image size? The version with in-place compression did have slightly lower vertical resolution; maybe that was making a difference?


Quote from: a1ex on February 02, 2018, 05:51:34 PM
Now compare with your version and see what parameters you have different: maybe image size?

My version is just a hack of commit 3b20239, running the new code on the 5D3 and the old code on all other cameras. In fact simply replacing only silent.c in the latest crop_rec_4k with the version from commit a9c8ad4 it will work on the EOSM/700D.

What seems to be different is that the "skip top bar" code was removed in the newer "do not compress DNGs in place" version. Is that where the slightly lower vertical resolution happens? We recently reduced the vertical resolution in the raw buffer for the 100D like the 5D3. Maybe that's needed here? Thing is, we also added some vertical resolution to the EOSM raw buffer.


The changes done for 100D and EOSM happen in a different place in the pipeline - before lossless compression. That issue is unrelated - there, the problem was at bringing the captured image into RAM. Now we've got the image into RAM, can save clean uncompressed DNGs, but the lossless encoder has some trouble compressing it.

Just print out_raw_info.width and height with your version, and with mine, then try modifying it (right before the call to lossless_compress_raw).


Wow guys! RAWLite (compressed raw) with sound included in the MLV in the latest 5Dmk3 update! Congrats to all of you who made it possible. I will battle test the beast and send results.


BTW the proxy dosent work with that but I think it's better to make proxys straight from Resolve.

Thanks again coding team!


Quote from: a1ex on February 02, 2018, 07:42:03 PM
Just print out_raw_info.width and height with your version, and with mine, then try modifying it (right before the call to lossless_compress_raw).

Ok, this is what I did:

    printf("out_raw_info.width %d\n", out_raw_info.width);
    printf("out_raw_info.height %d\n", out_raw_info.height);

    out_raw_info.frame_size = lossless_compress_raw(&out_raw_info, out_suite);

On the EOSM with the old version of silent.c, commit a9c8ad4, it reports on the console:

out_raw_info.width 5280
out_raw_info.heigh 3477

However, your current version reports:

out_raw_info.width 5280
out_raw_info.heigh 3529

Next I tried changing the height with:

out_raw_info.height = 3477;

and it saved a compressed DNG but this is obviously not the way to do it because the file wouldn't open.

[EDIT] I take it that this test doesn't apply to FRSP?

In [1]: 5280*14//8*3477 % 16
Out[1]: 8

In [2]: 5280*14//8*3529 % 16
Out[2]: 8


Try adjusting out_raw_info.active_area.y2 too (decrease it by the same amount). If that works, can you try intermediate sizes to see where it breaks?


It works! Turns out that height -1 is all that's needed.

    out_raw_info.height = 3528;
    out_raw_info.active_area.y2 = 3528;

So taking what we learned recently with the 100D, I tried this and it works too:


Would there be a problem if this is applied to all of the cameras?


Probably not. In photo mode, I take the size directly from EDMAC configuration; double-checked with the transfer model and appears to be right the way it is now:

height = shamem_read(RAW_PHOTO_EDMAC + 4) + 1;     /* size N */

On 5D3, this gives an even number (also visible in, channel #0). On 700D/M/100D, I assume that's an odd number. Maybe force it to be always even?

height = shamem_read(RAW_PHOTO_EDMAC + 4) + 1;     /* size N */
height &= ~1;