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

pc_bel

Sorry if it was commented before.
When I'm in croprec in 1920_50p 3x3 mode and use SET button to enter in 5x to focus, all is ok but in the next SET press to go to 10x, liveview freezes and I'm forced to stwich off camera (5D3 1.1.3 with external monitor connected via hdmi) Last 22 july build.
Canon menu is in 50p mode and camera records images in 50p with no problem.

Somebody has the same problem?.

Thanks!!!

Michael Vito

Similar behavior here with 1920 50p 3x3 on 5D3123. I don't use SET, just the default zoom button (magnifier glass). Did you remap yours? I can get to 10x, but it freezes when I hit zoom again to return to normal view. If I try to sneak out of zoom mode by hitting Menu, I get a black screen when returning to Live View.

pc_bel

QuoteDid you remap yours?
No, by default the SET button act as magnifier (in my case)...

I returned to a previous build and all is ok now.

jimiz

the last on 5d3 have problems , read back the comments...
5D3-123

Kharak

try setting half-shutter press to Clear Overlays and hold the half shutter as you do the zoom in, see if it bypasses the problem. In 60p 3x3 this works for me.
once you go raw you never go back


Kharak

Bonus Info: Holding half-shutter press for clear overlays while recording 50/60p/3.5k etc increases record times substantially.
once you go raw you never go back

MartijnR

I have been using the crop_rec (5D Mark III) for a project last year, and the short film is now in the festival circuit and has several official selections, so I am very grateful. There was however a problem using the crop, where there where lines or complete error segments once in a few seconds (see attached). I first thought it was the specific version of the crop_rec firmware, but now that I have the latest version installed (in the experiments folder) for a new film project, I have these errors again. I haven't tested it yet in the non-crop_rec version, but is this something common? I am probably doing something wrong. Thanks for any help.

BTW I have been using the 3.5K centered x5, 2.35:1, 3072 x 1308, and have the errors in 14bit lossless, and if I recall well, also in 12bit lossless and 10bit lossless.




a1ex

Quote from: theBilalFakhouri on September 24, 2018, 10:30:34 PM
I noticed flickering with new crop_rec it becomes stronger when using high shutter speeds such as 1/500 1/1000 etc

700D, 1080p24, 1/4000:
FPS timer A = 528, B = 2527/2528
ADTG[8061]: 0x9d1/9d2 = 2513/2514

Locking just one of them in adtg_gui to some value introduces flicker.
Locking both of them gets rid of the flicker.

In adjust_shutter_blanking, current_blanking is going back and forth between two adjacent values; since our timer B is fixed in crop_rec, we may need to get rid of these variations for current_blanking, too.

Why is that? We need to get rid of variations in exposure time, i.e. timer B - blanking (where one unit = timer A / FPS clock). If you do the math, 14 vs 15 units of exposure time means ~ 0.1 EV of flicker. At large exposure times, this is no longer noticeable.

Draft patch for the bleeding edge crop_rec:

--- a/modules/crop_rec/crop_rec.c
+++ b/modules/crop_rec/crop_rec.c
@@ -558,4 +558,11 @@
     int current_blanking = nrzi_decode(old);

+    static int previous_blanking = -1;
+    if (ABS(current_blanking - previous_blanking) == 1) {
+        current_blanking = previous_blanking;
+    } else {
+        previous_blanking = current_blanking;
+    }
+
     int video_mode = get_video_mode_index();


Homework: point out the bug from the above code (yes, there is one).

Kharak

Quote from: MartijnR on October 26, 2018, 03:20:43 PM
I have been using the crop_rec (5D Mark III) for a project last year, and the short film is now in the festival circuit and has several official selections, so I am very grateful. There was however a problem using the crop, where there where lines or complete error segments once in a few seconds (see attached). I first thought it was the specific version of the crop_rec firmware, but now that I have the latest version installed (in the experiments folder) for a new film project, I have these errors again. I haven't tested it yet in the non-crop_rec version, but is this something common? I am probably doing something wrong. Thanks for any help.

BTW I have been using the 3.5K centered x5, 2.35:1, 3072 x 1308, and have the errors in 14bit lossless, and if I recall well, also in 12bit lossless and 10bit lossless.





I've never used any of the lower lossless bit depths with 3.5k or 3k crop_rec and I've never had footage corrupt like that. Are you sure this also happened with 14 bit lossless 3.5k/3k?

I am on fir 1.2.3

Edit: how fo you process the MLV's? What program do you use?
once you go raw you never go back

theBilalFakhouri

Good stuff @a1ex

Quote from: a1ex on October 28, 2018, 10:24:21 PM
Homework: point out the bug from the above code (yes, there is one).

I have a homework also for you; there is a bug in the generic code when using other PowerSaveTiming registers that are not necessary for 700D, keep ADTG 8172  8178  82b6 and comment out the others ADTG.

I have used 1x3 Binning setting Y res to 2214 and Dual ISO 100/3200.

Just kidding :P what I am saying I am not a coder at least for now to do coding homeworks hahaha but the problem is there; It's some kind of flicker(Low contrast frame/High constrast frame something like that) I thought it was from shutter speed bug or aggressive 100/3200 Dual ISO but using same Dual ISO and without crop_rec the problem is gone. That's how I found the problem wasn't from Dual ISO and shutter speed bug (shutter speed was set to lowest value so no flicker was happening) then I tried to comment out other ADTG registers and the problem has been fixed.

I didn't search to find out which specific ADTG registers causing this but the point is not to use unnecessary registers for all cameras maybe that isn't good thing. For small cameras (700D, 650D, 100D and EOS M) the necessary ones is 8172, 8178 and 82b6. I don't have my cam and laptop right now posting examples next week.

Also after commenting out these ADTG registers some new focus pixels showed in 1x3 Binning mode.

a1ex

Interesting; I've also noticed ADTG 8196 and 8197 have different values and poked them last night to look for side effects, but could not notice any. Will try to reproduce, just not sure what to look for.

Is it enough to comment out ADTG 8196 and 8197? 8173 and 8179 are required according to my theory, and should be noticeable at high vertical resolution and might also have an impact on sensor power consumption and temperature (I did not do any measurements; it's just what I think they might do). 82F8/F9 are only present on 5D3, so keeping them in the source would have no effect on other models.

Here's a (draft) graphical view of LiveView configuration for 700D, where you can see these outliers:



Same for 5D3:


60D:


5D2:


5D4 (from here):


These graphs were created from io_trace_full logs; will prepare some test builds later for other models.

damien

Hi Everyone,

when using the 3.5K centered mode (2640x1320), i cannot set the shutter speed above 1/140e is there something i'm missing?

i'm on 1.2.3 with ML from july using PAL 25P

a1ex

Could not reproduce (1.1.3 with vanilla July 22 build).

With default settings, I could get speeds between 1/33 and 1/4300 in centered x5 zoom mode at 24/25/30p. With "full range" shutter speed enabled, I could select between 1/FPS (i.e.1/24 or 1/25 or 1/30) and 1/23000.

To get exactly 1/140, I had to use shutter fine-tuning. I couldn't get the "e" suffix; assuming typo.

Didn't measure these shutter speeds against a calibrated reference, so take the printed numbers with a grain of salt. I've only tried to match them with Canon readings and made an educated guess from there.

MartijnR

Quote from: Kharak on October 28, 2018, 11:24:25 PM
I've never used any of the lower lossless bit depths with 3.5k or 3k crop_rec and I've never had footage corrupt like that. Are you sure this also happened with 14 bit lossless 3.5k/3k?

I am on fir 1.2.3

Edit: how fo you process the MLV's? What program do you use?

Hi Kharak,

Thanks for your comment. Yes, I am sure it happened on 14bit lossless. I have done a lot of testing to seek for the best image quality and recorded in different test settings. In the end I went for 14bit lossless because the quality seemed the best. However, I am now not so sure anymore if I actually recorded the way I wanted (crop in highest image quality setting). I am on firmware 1.1.3.

As for MLV process software I have used a lot, cr2hdr, Footage, MLV App and others, and they all show the same errors on the same timepoint in the clips. However, somehow I didn't, and still do not, seem to get the MLV Dump specifically for the crop running. Not in Terminal (Mac), and also not linked to other software. Maybe this is the problem.

I would be very thankful if you (or somebody else) could process the clip (macro of walnut)  with the specific crop MLV Dump software in my dropboxlink. If you also have the errors around second 1 and second 4, then at least I know it is in the MLV files themselves, and not in the process software.
Also, I wonder if you can see if this small clip has indeed the high quality of the crop setting you can obtain (lens is otus (reversed), and lighting was fairly good (iso 1600 though), so the image quality should be high).

https://www.dropbox.com/sh/au5lkf1cfwq1qp7/AADdRbNh5jBK_s5zx4r8X6pva?dl=0

Thanks!


a1ex

Might have found out where the FPS timer B overhead comes from, on 5D3:



Previously, I've noticed timer B overhead (i.e. difference between vertical resolution and minimum timer B that still gives clean image) was a bit hard to figure out; it wasn't a plain number that I could just hardcode in crop_rec. I could notice the overhead is larger in high-FPS modes and smaller at large resolutions (such as 4K half-FPS), but could not quantify it, so I had to tune each preset manually. Now I've confirmed a hypothesis I had since looking into 5D2: the overhead for timer B is, indeed, constant, but measured in milliseconds.

The red line shows the timer B limit found experimentally in the old FPS override code. Notice it matches the last red marker.

Between the red markers, EvfState executes its state transition functions; in particular, evfSetParamInterrupt and evfReadOutDoneInterrupt. During the last transition (last pair of red markers), Canon code sets up the hardware for capturing the next frame. This process is quite complex and... takes a significant chunk of execution time on the ARM processor (about 2.3 ms).

According to that graph, the 1080p60 can be easily pushed to 70 FPS without sacrificing resolution. Whether that can be recorded, I did not test.

If that software reconfiguration can be somehow optimized (e.g. by caching the register values configured by Canon code, and just replaying them for every frame), the 720p mode can - in theory - be pushed to about 83 FPS. Probably not worth the effort, as the lossless encoder is likely to be unable to keep up, the rolling shutter would be very close to 100%, and so on.

Our raw video "vsync" hook is placed right at the last red marker (it's executed right after Canon code does its evfReadOutDoneInterrupt transition, i.e. it extends the duration of that), so whatever we do there might also limit the maximum frame rate, to some extent.

Also notice the evfSetParam event sometimes starts to be processed *after* the HEAD3 interrupt (which signals the evfReadOutDoneInterrupt event). That might result in corrupted frames (unconfirmed hypothesis). Reducing the value of HEAD4 (which triggers evfSetParamInterrupt) *might* fix these corrupted frames (again, unconfirmed hypothesis).

Here's what happens if one reduces HEAD4 from 1320 to 1000 in 1080p24, timing-wise:



In other words, it appears to help, but that's not the only cause of delayed frames.


MacMillan



a1ex

Some more LiveView timings:



Quote from: DeafEyeJedi on April 13, 2017, 03:59:09 PM
Let's keep tinkering down on this one please. 1080p 48p is crucial. Especially for HDR video kind of work.

Based on the above picture, I'd suggest the following settings:
- current July 22 build from Experiments page
- crop_rec, 1080p45/1040p48 preset, 60 FPS in Canon menu
- Target YRES: dial 1080 there
- Delta HEAD4: -100 (value not critical; -50 or -200 should work just as well)
- Delta HEAD3: fine-tune between 0 and -20
- press MENU twice to apply the new settings

With DH4=-100 and DH3=-10 I've got clean clips at YRES=1100 (i.e. slightly higher than the desired target of 1080). You don't have to use 1100; the goal is stable recording, without corrupted frames, at 1080p48. I've tested at 1100 just to ensure a small safety margin.

Please check for corrupted frames in recorded videos and report back.

70MM13

Are you able to get continuous recording at 1080 48fps?

I'd like to know what to expect before I begin the test.

Danne

Why not just do the test and see what you get @70MM13 8)

I got 1920x1080p 48fps working with a1ex proposed settings. How awesome is that!
No corruption with Delta Head3 set to -20. Started out at -14 and -10 but gave me corrupted frames and logs on the screen.

EDIT: Lovered registers directly in here and got it working as well:
        /* HEAD3 timer */
        /* 2E6 in 50p, 2B4 in 60p */
        case 0xC0F0713C:
            return 0x2B4 + YRES_DELTA + delta_head3;

        /* HEAD4 timer */
        /* 2B4 in 50p, 26D in 60p */
        case 0xC0F07150:
            return 0x26D + YRES_DELTA + delta_head4;

to:
        /* HEAD3 timer */
        /* 2E6 in 50p, 2B4 in 60p */
        case 0xC0F0713C:
            return 0x2A4 + YRES_DELTA + delta_head3;

        /* HEAD4 timer */
        /* 2B4 in 50p, 26D in 60p */
        case 0xC0F07150:
            return 0x22D + YRES_DELTA + delta_head4;

And of course:
    [CROP_PRESET_3x3_1X_48p]    = { 1290, 1290, 1290, 1080, 1040, 1320 }, /* 1080p45/48 */
to:
    [CROP_PRESET_3x3_1X_48p]    = { 1290, 1290, 1290, 1080, 1048, 1320 }, /* 1080p45/48 */

70MM13

Nice!
It works for me also, starting at -17.
-16 gave a black frame, and a screen full of errors, but it kept recording anyway.
I only get about 1000 frames before it can't keep up.

mothaibaphoto

I need Delta HEAD3 to be -30 - then only a dozen of first frames are "jumping" left-right, and record continues without artifacts. With any other value(-20, -17, -15, -10) - frames corruption, flickering, console messages about corrupted frames and compression errors. :(