Magic Lantern Forum

Hi everyone
I apologize in advance if I did not express myself well because I am french.

With my Canon EOS M I can shoot in RAW 1280x720 continuously but I wish I could shoot in 1792x1008 more than two seconds so I spent the whole night on the forum and I saw that it was possible to film 12 fps and recreate the missing frames with Twixtor .
So I immediately tried activating the FPS override function and selecting 12 fps and optimized for exact fps.

But I have two problems :
-My exposure is good (f/11; 1/250 shutter; and ISO 160) and when when I enable FPS override feature the exposure change : It's completely overexposed, even if I change the shutter speed the exposure is the same and the histogram don't change.
-The second problem is that when I chose optimizeed for exact fps I have a black bar on the right side of my video while that does not appear in the low light mode.

Thank you in advance
Magiclanterner

Are you shooting in M mode?

Quote from: Magiclanterner on April 14, 2015, 05:35:18 PM
-The second problem is that when I chose optimizeed for exact fps I have a black bar on the right side of my video while that does not appear in the low light mode.

This one is a bug. Looking in the code history, Coutts ported it from Tragic Lantern without trying it, and FPS_TIMER_A_MIN/FPS_TIMER_B_MIN are completely bogus. I actually wonder why it works...

To fix it, set FPS_TIMER_A_MIN and FPS_TIMER_B_MIN to a very low value, then, for each video mode, find the lowest timer value which still gives a good image without artifacts (by trial and error, starting from default FPS, fine-tune one timer manually from ML menu). The good news is that those timers are independent (timer A gives the time to read one line, and timer B gives the time for the entire frame - see comments in rolling_shutter_print). Watch out for the vertical black bar on the right side (visible especially in RAW). Usually, the minimum timer value is a few units below the default value.

Note that video modes on EOS-M are different when recording and when not, unlike all other cameras.

Sorry, want to help but i can't get it...

QuoteTo fix it, set FPS_TIMER_A_MIN and FPS_TIMER_B_MIN to a very low value, then, for each video mode, find the lowest timer value which still gives a good image without artifacts (by trial and error, starting from default FPS, fine-tune one timer manually from ML menu). The good news is that those timers are independent (timer A gives the time to read one line, and timer B gives the time for the entire frame - see comments in rolling_shutter_print). Watch out for the vertical black bar on the right side (visible especially in RAW). Usually, the minimum timer value is a few units below the default value.

Note that video modes on EOS-M are different when recording and when not, unlike all other cameras.

1. Cleared all ML settings. (to be clean)
2. Canon Movie mode, 1920x1080p25, Manual.
3. Enabled FPS Override in ML : 30 (from 30), exact FPS
4. Started recording H.264
5. Opened ML menu while recording and started to play with FPS timer A and FPS timer B

But no change or artifacts noticed on the LV image.

What i'm doing wrong ?

Did you notice any change on Actual FPS in menu?

If yes, just keep decreasing timer value. At some point, one of those should happen:
- Actual FPS no longer changing (that means, FPS_TIMER_*_MIN can be defined to a lower value)
- image artifacts appear (in this case, write down the timer value)

Yes.

Quote- Actual FPS no longer changing (that means, FPS_TIMER_*_MIN can be defined to a lower value)

FPS timer A : 520 (FT-12)
FPS timer B : 1970 (FT-81)

(http://s10.postimg.org/qqzkgsipl/FPS.png)

Have tried to reproduce this :

QuoteBut I have two problems :
-My exposure is good (f/11; 1/250 shutter; and ISO 160) and when when I enable FPS override feature the exposure change : It's completely overexposed, even if I change the shutter speed the exposure is the same and the histogram don't change.

For me everything is working, i can change the aperture or shutter and the histogram is changing accordingly. (i have expo. Override enabled)

And the black bar (only appearing in crop mode) on the right disappear with a value of FPS timer A 534 (FT+4)

Quote from: vertigopix on April 28, 2015, 12:35:18 PM
FPS timer A : 520 (FT-12)
FPS timer B : 1970 (FT-81)

Those are safe values, or the values where artifacts start to appear?

Can you repeat the process for all resolution and FPS modes from Canon menu? Also include photo mode and 5x zoom mode (just once; zoom is the same in all video modes).

Safe values.

1920x1080p24 : A 520, B 1970
1280x720p50 : A 520, B 1970
640x480p25 : A 520, B 1970
Photo Mode : can't see, no image in background of the ML menu...
Zoom mode : can't see, no image in background of the ML menu... (but do you mean Crop Mode ? In that case A safe value is 534)

But just a question :

I have noticed that i can't go lower than 520 and 1970. The value doesn't change in the display. (But the FT value is still changing)
Is it an "hard limit" in the ML code ?

FPS_TIMER_A_MIN and FPS_TIMER_B_MIN are the hard limits you are trying to find. Lower values are unsafe, but you need to find how low you can go, so first define it to something like 100. Even with those bogus values, if you start at default FPS, ML should pick default timer values, which are safe. From there, you try to push them until the image breaks.

With the bogus hard limits, there are modes that work just fine, and modes that do not work at all. The safest option would be to never allow overcranking, but then the exact FPS option may not be able to find an exact solution (since it usually overcranks one timer a bit, but "relaxes" the other). So, the best way is to allow a tiny bit of overcranking, but we need to find out how far we can go, and then go back on the safe side a bit.

Current values appear to be tweaked for one particular video mode only (probably 30fps). See https://docs.google.com/spreadsheet/ccc?key=0AgQ2MOkAZTFHdFFIcFp1d0R5TzVPTVJXOEVyUndteGc#gid=3 for default timer values.

Examples of why the current values are bogus:
- at 25/50 fps, default timer A is 640. Cranking it to 520 sounds a bit too much to me, unless you use NEW_FPS_METHOD.
- at 24fps, default timer B is 2527. Cranking it to 1970 also sounds a bit too much.
- EOS M applies some FPS settings only when you record H.264 (unlike all other cameras), and current hard limit definitions do not consider this.

To see behind ML menu, normally you need to press the LiveView button or the Zoom In button. Do you have any of those on M?

If not, tag the menu entries you want to edit with LiveView visible, with this:

                .edit_mode = EM_MANY_VALUES_LV,


Values at 50 fps can't be equal to those at 25. Those are probably in standby mode, where EOS M uses 30 fps, no matter what Canon settings you have.

There are also 30fps and 60fps modes.

Crop mode and 5x zoom are not the same thing. You posted some dumps a while ago, so you already know these modes.

Quote- EOS M applies some FPS settings only when you record H.264 (unlike all other cameras), and current hard limit definitions do not consider this.

Have tested while recording H.264

QuoteTo see behind ML menu, normally you need to press the LiveView button or the Zoom In button. Do you have any of those on M?

No LV (Mirrorless) and the Zoom In is on touch screen, if i activate it (5x) and press REC the LV get back to no zoom.

QuoteCrop mode and 5x zoom are not the same thing. You posted some dumps a while ago, so you already know these modes.

;)

From this evening to monday i go to Croatia.  8) So i will try when i return... If i return !
BUT... I want to film with my M in RAW... Is it risky ? (i just want to use FPS override to get 25)

@vertigopix:

Not really. Definitely give it a shot with the M. Try avoid using high ISO's (unless you don't mind dealing with pink dot removal in post) other than that it is a great toy for trips!  8)

Quote from: a1ex on April 28, 2015, 01:58:28 PM
FPS_TIMER_A_MIN and FPS_TIMER_B_MIN are the hard limits you are trying to find. Lower values are unsafe, but you need to find how low you can go, so first define it to something like 100. Even with those bogus values, if you start at default FPS, ML should pick default timer values, which are safe. From there, you try to push them until the image breaks.

setting timers like instructed and recompiling crashes 70D even though ML is picking default timer values with continuous crashlog writing to sdcard (crashxx.log). all crashlogs contain:

Quote
ASSERT: !IS_ERROR( TryPostEvent( this->hTaskClass, this, EV_RESET_PSAVE_INTERRUPT_EVF, NULL, 0 ) )
at ./Evf/EvfState.c:401, task ?
lv:1 mode:2


Magic Lantern version : Nightly.2015Apr28.70D111A
Mercurial changeset   : 1ace8a558a3a+ (70D-merge) tip
Built on 2015-04-28 19:34:03 UTC by ml@ml-pc.
Free Memory  : 231K + 1935K

I took a look at the state diagrams but looks like I could need some helping hands. How could fps-override crash the cam even if CONFIG_FPS_UPDATE_FROM_EVF_STATE is undefined:
http://a1ex.bitbucket.io/ML/states/70D-alt/sm17.htm

I get the same limits.
Do I need to lower them in code and recompile or what?

Yes, you need to lower them in the code in order to perform the tests.

Edited /src/fps-engio.c and lowerd A from 520 to 420 and B from 1970 to 1870
#elif defined(CONFIG_EOSM)
    #define TG_FREQ_BASE 32000000
    #define FPS_TIMER_A_MIN 420
    #undef FPS_TIMER_B_MIN
    #define FPS_TIMER_B_MIN MIN(fps_timer_b_orig, 1870)


Now this will get me to: https://imgur.com/a/HfZh0 (https://imgur.com/a/HfZh0)
Screenshot 1: lowest A I can go before visible artifacts is 512
Screenshot 2: For A under 520 the image gets shifted to the left ( about 11 pixels at 512 ), you can see the small black vertical band on the right side of the screen.
Screenshot 3: Going for A under 512 will yield corruption, trying different values for a while will make the display stay corrupted a bit even when backing up to 512.

Only playing with A yields corruption, fiddling with B will just shift the "Actual framerate" but I did not get corruption in my little time testing it, when the value is high ( say 5000 for 12fps out of 30 ) it gets boring to test it :P

The B timer has different values for different FPSs, how is this related to 1870/1970 set up in ML?

OK, so for timer A, 520 appears to be a good choice for the video mode you tested.

For B, you'll get corruption only if you lower it (higher FPS), so there's little point in testing higher values.

After that, create a table with all video modes and write down the safe timer values for each one.

I passed through all the modes in the previous test too, A as 520 still holds out ok.

Now, for B I can't really get my head around it: (base?) values jump around when changing desired FPS and if I lower B then the actual FPS is raised making the whole point of having an exact FPS useless, say I can get 1920x1080@25720@50, desired fps 12 (exact), put A on 520, lower B to 14xx hence actual fps yields 48 (!?).

Looking at the OP:

Quote-My exposure is good (f/11; 1/250 shutter; and ISO 160) and when when I enable FPS override feature the exposure change : It's completely overexposed, even if I change the shutter speed the exposure is the same and the histogram don't change.

Looks like it's working here, but maybe I did not understand the issue, I got a good exposure in photo mode ( f/11, 1/30, ISO400 ), switched to video, matched it, then set fps override to 12, went to shutter range there and pulled it to 1/12..1/30, when't back to shutter and set it up to 1/30... and it's ok. BUT I'm not sure you can even go as high as 1/250 though, you should be able?

Quote-The second problem is that when I chose optimizeed for exact fps I have a black bar on the right side of my video while that does not appear in the low light mode.

I don't see any bars. ( except lowering A that is )


/LE: was 720 not 1080 sorry

You don't have to get an exact FPS when doing the test.

Also, remember that, on EOS M, FPS on standby (when not recording) is not affected by Canon FPS settings, so you also need to do the tests while recording H.264 (not just in standby).

Did it recording H.264 too.

That means, you were able to record 48fps H.264 without artifacts?!

in 720@50 ( https://i.imgur.com/vGmbdGq.png (https://i.imgur.com/vGmbdGq.png) ) in PAL, I guess that's not a feature, you though 1920@48? Nope.


Also a heads up, see the picture above, switching to 720@60 in NTSC yields 20 ( from 30FPS) in the ML menu, both in StandBy _and_ during recording, while in 720@50 mode it's 30 standby and 50 during recording, strange.

so what is needed to fix fps override just some changed timer check frequency values, or is it way more complicated. i'm just trying to wrap my head around what needs to be done that's all.

I'm just starting to experiment compiling ML and found out that this issue is currently causing build failures on the EOSM. Maybe this is intentional? In any case, in fps-engio.c starting on line 232 is the FPS_TIMER_A_MIN and FPS_TIMER_B_MIN timer values.

#elif defined(CONFIG_EOSM)
    #define TG_FREQ_BASE 32000000
    #define FPS_TIMER_A_MIN 520
    #undef FPS_TIMER_B_MIN
    #define FPS_TIMER_B_MIN MIN(fps_timer_b_orig, 1970)
    #error fixme: FPS_TIMER_B_MIN and FPS_TIMER_B_MIN are plain wrong

When I comment out that last line it compiles and runs fine on my camera. I can try to follow the instructions on this discussion and experiment with different values but has that already been figured out?

By the way, I'm using dmilligan's excellent instructions for compiling ML in the cloud:

http://www.magiclantern.fm/forum/index.php?topic=14725.0

It's intentional, so that we M users take a stab at it, we did but with questionable success.

The defaults:


(https://bitbucket.org/repo/8b7b/images/2159206870-ML_eos-m_fpsoverride_timers.png)

Alright. So, in crop mode, the FPS settings are applied right away, but in non-crop, they are applied only when you start recording. Didn't know about this.

In those modes where timer A is 640, can you decrease it all the way down to 520?

Then, in those modes where timer B is over 2400 (most 24fps modes), can you decrease it all the way down to 1970?

If yes, that is quite unusual for a camera that doesn't use NEW_FPS_METHOD (these were the red flags for me).

Minimum (almost all results;  just drained a second full battery for these tests :-\ ):

(https://i.imgur.com/DHBtmbE.png)


And the link: https://mega.co.nz/#!FABkBDxY!hUMMZUdyzAAfvo5SZJYxh-_IsT-5bNXtTz_8RRN9PwY

And those missing:
Photo Mode Minimum: A 520 B 1965
Zoom Mode Minimum: A 666 B 1242

Now, how about unblocking the builds then. :P

Will do as soon as I get some time to do the math (that is, more than 10 minutes at the PC).

Quote from: a1ex on June 21, 2015, 08:29:04 PM
Will do as soon as I get some time to do the math (that is, more than 10 minutes at the PC).

Don't mean to pester you, we know you got a lot on your plate but is there anything else we EOS-M users can do to help with this? There has been some cool new features along with bug fixes since the last working nightly build. :'(

I just noticed something interesting--rather funny in a way.

Searching how this timing thing works I came across this "updated" spreadsheet [ML] Canon EOS Features Comparison - FPS Comparison (https://docs.google.com/a/digiola.com/spreadsheet/ccc?key=0AgQ2MOkAZTFHdFFIcFp1d0R5TzVPTVJXOEVyUndteGc#gid=3). Scroll down to the bottom where the EOS M is listed and notice the values in columns M through O.

0xDEAD    0xDEADBEEF

Ok, I know that 0xDEAD and 0xDEADBEEF are hex numbers but  :o  ???  ::)  :-\ not any closer to figuring this thing out. These numbers don't look anything at all like Licaon_Kter's tables or what coutts reported in the very early porting stages (http://www.magiclantern.fm/forum/index.php?topic=3648.msg19380#msg19380). Am I looking in the right places to educate myself?

0xdeadbeef is usually just a place holder, it's meaningless (dead beef) and it conforms to the need of hex numbering (0..9a..f). My guess is that this value is not actually known.

https://en.wikipedia.org/wiki/Hexspeak

Thanks for the Hexspeak lesson  ::)

according to otheronepercent as of last december:

#elif defined(CONFIG_EOSM)
    #define TG_FREQ_BASE 32000000
    #define TG_FREQ_SHUTTER (ntsc || NOT_RECORDING ? 56760000 : 50000000)
    #define FPS_TIMER_A_MIN (fps_timer_a_orig - (ZOOM ? 10 : MV720 ? 10 : MV1080CROP ? 10 : 10)) /* Can relax a little more but get black bar */
//~ #define FPS_TIMER_A_MIN MIN(fps_timer_a_orig - (ZOOM ? 0 : 20), ZOOM ? 716 : 520)
//
#undef FPS_TIMER_B_MIN
    #define FPS_TIMER_B_MIN (fps_timer_b_orig - (ZOOM ? 261 : MV720 ? 127 : MV1080CROP ? 1204 : 127))
//IDLE 2022 1895
//CROP 2444 1240
//5X 1491  1200~1230


and these values allow me to record up to 45fps before I start to see artifacts, but he's doing other stuff too, how do I look at a differential between his fork and the current unified? when I click the "diff" button it seems to be comparing to an older version of unified

You can't directly compare there.
Use a local diff:


1: https://i.imgur.com/Q9WAh3z.png


2: https://i.imgur.com/0AcMhrF.png

Reformatted the table with the differences: https://mega.co.nz/#!9BBkEZZa!oqhQsDTgx4tK4eJ2vToYAvIU_wvafmFDoPKPJOKtPAY (https://mega.co.nz/#!9BBkEZZa!oqhQsDTgx4tK4eJ2vToYAvIU_wvafmFDoPKPJOKtPAY)


(https://i.imgur.com/IAhC6Ua.png)

So according to your spreadsheet, the safe values would be:

#define FPS_TIMER_A_MIN (fps_timer_a_orig - (ZOOM ? 10 : MV720 ? 8 : MV1080CROP ? 14 : 8))
    #undef FPS_TIMER_B_MIN
     #define FPS_TIMER_B_MIN (fps_timer_b_orig - (ZOOM ? 249 : MV720 ? 25 : MV1080CROP ? 208 : 57))


but this gives rather unimpressive framerates for overcranking. Someone who always has canon menu set to 24p (Me) could safely go up to 697. Should we put condition to check if camera is set to 24p,25p,30p? Proposals? 

Oh well, the encoder can only handle 34 fps at 1080 anyways until we reimplement GOP controls, (Up to 45fps with GOP1) so i guess this is good enough for a pull request to fix nightlies in the meantime. Thanks for your hard work making the table and doing the math. Please test with the above code and let me know if you have any problems. it's working fine here, if you can confirm i'll make the PR.

Where did you got the value for ZOOM ? 10 ? Why not 50 ?

Yes, this needs an Euro check ( aka 25p, 50p ) too. :D

Can you paste a real diff or point us to your bitbucket repo so I can build it right? You will need one for the pull request maybe anyway?!

Also, do detail how the test procedure goes on, as I did not fully grasp what the problem was in the first place. :P


10x

I left it at 10 because I know it's a safe value, and your table did not have a value posted for zoom during recording, (which is probably lower than 50)

test procedure is try a bunch of different fps settings in the various modes and tell me if you experience artifacts with any of those settings. Our goal is to have the widest range of fps without artifacts. I can post a test build when i get home, but if you don't want to wait, just replace fps_timer_a_min and fps_timer_b_min with the code above and rebuild.

Actually I just tried to submit the pull request, but bitbucket keeps getting hung up on "creating pull request" - i'll try to do it through atlassian

here is fpsengio.c with the changes: https://www.dropbox.com/s/miymaagfgldydgg/fps-engio.c?dl=0

Quote from: dpjpandone on August 13, 2015, 07:33:39 PM
I left it at 10 because I know it's a safe value, and your table did not have a value posted for zoom during recording, (which is probably lower than 50)

How do I zoom while recording?

Quote from: dpjpandone on August 13, 2015, 07:33:39 PM
test procedure is try a bunch of different fps settings in the various modes and tell me if you experience artifacts with any of those settings. Our goal is to have the widest range of fps without artifacts.

Yes but what exactly? Detail how you test: what Canon mode/fps? What ML fps override value? What fps mode ( jello, fix, other)? the whole procedure. I'm not that of a video shooter hence my lack of direction.

Quote from: dpjpandone on August 13, 2015, 07:33:39 PM
Actually I just tried to submit the pull request, but bitbucket keeps getting hung up on "creating pull request" - i'll try to do it through atlassian

Link of your repo? So I'll clone it and test directly ( since you have the early stuff with shutter fine tuning and the rest there too, right? )

Test procedure:

via fps override menu:


1.raise "desired framerate" as high as it will go, (until "actual fps" stops changing) and check for artifacts
2.lower "desired framerate" as low as it will go, (until "actual fps" stops changing) and check for artifacts

then repeat this procedure for each mode on your table (1080, 1080 crop, 720, 480, 5X zoom - do each of these with canon menu set to 24p, 25p, 30p, 50p, 60p)

It's going to be really boring testing all those modes, but if the values in your table are correct, they should all work without artifacts.

The pull request is here: https://bitbucket.org/dpjpandone/dpjpandone-eosm-fixes/pull-requests/1/fps_timer_a_min-and-fps_timer_b_min-fixed/diff

in order to get it merged into main, we have to confirm that all these modes are working.

No pull request for button navigation yet, because although it's working, it's not clean enough to be approved. I am awaiting response in general development thread to find out what needs to be done to make it "acceptable"  also, no one has answered my question as to why shutter fine-tuning was disabled in the first place so no PR for that yet either.

fps should be our first priority for PR so nightlies can work again.

You are right, there is no way to zoom during record. I was thinking of raw record (in 5x zoom mode) but I don't think fps changes there like it does with h.264 - so it is probably ok to set it to 50. I'll test and if it's fine I'll change in the PR

Also,just realized euro check is not necessary, as the end result is the same, example: encoder limit without video hacks is about 34fps. Setting timer b min to a larger number let's you overcrank from 24p to 34fps, setting it to 208 only let's you crank to 26fps (from 24p) but if you switch to 30p, you can still crank 30p to 34 fps. So putting a check in there will only complicate the code, and we're still limited to 34fps anyways. 

Quote from: dpjpandone on August 13, 2015, 10:59:16 PM
1.raise "desired framerate" as high as it will go, (until "actual fps" stops changing) and check for artifacts

1080@30 max is 31.317fps
1080@24 max is 24.904fp

Kinda underwhelming...

Quote from: dpjpandone on August 13, 2015, 10:59:16 PM
2.lower "desired framerate" as low as it will go, (until "actual fps" stops changing) and check for artifacts

At least 1080@24/30 goes as low as 0.616fps.

Is this correct?

I have had stable and reliable results with my timer B values set to a much larger number (large enough for me to overcrank from 24fps to 45fps and higher using low light method)... but with the values from your table, this is as high as we can go, I'm afraid....

So, it seems to me that these are our options:

1. Leave the values as they are (since you have confirmed them to be safe) and leave the pull request unmodified in hopes that it will be merged as soon as possible, to fix nightly builds
2. Backout the changes in the pull request and do more testing to see if it can be pushed further (just in case a mistake was made when you made the table initially) in hopes that we can agree on safe values that allow for overcranking to at least 35fps
3. Modify values in pull request now so that it can be cranked to at least 35fps (and change them later if anyone else experiences artifacts/problems)

I think option 3 would be ok, since they were initially set to a much higher value anyways, what started this whole "intentionally breaking nightlies" thing was that someone reported an issue, and Alex noticed that the values were wrong.

I think the values for timer A are good, and .616 is an acceptable limit, but I am pretty disappointed with the values of timer B. I would like to use a value that at least allows us to overcrank to the limit of the encoder. The only time I experience artifacts is when The shutter speed is accidentally set too low, but I usually use an 180 degree shutter (because I'm a video guy) so I guess maybe I didn't run into the same stuff you were seeing with whatever shutter speed or FPS override method you used when you made your table.

Would you be willing to do some more testing to see if any of the values in your table can go a little higher? I would recommend keeping your shutter angle as close to 180 degrees (or fps*2) when testing for timer B

I'm sorry to ask you to do this again, unfortunately I was not involved in the conversation when you made the table initially.

Also, do people want lower fps than .616 or is this good enough?

Quote from: dpjpandone on August 21, 2015, 11:22:16 PM
Would you be willing to do some more testing to see if any of the values in your table can go a little higher? I would recommend keeping your shutter angle as close to 180 degrees (or fps*2) when testing for timer B

Which values exactly do you mean to "go higher"? The difference?

Yes. Since we are happy with the timer_a_min values, leave them the way they are, but set timer_b_min back to:

#define FPS_TIMER_B_MIN MIN(fps_timer_b_orig, 500)

and see how low you can push timer b before you have problems (remember to keep your shutter speed at 180 degrees, as this is how you would use the feature when shooting videos.  so if you are starting at 24fps, shutter at 1/50)

When you are testing the 3x crop mode, start with desired fps set to 45, and then start lowering timer b from there (it will save you lots of time and put timer a at a realistic value)

here are the values from my own testing:

FULL FRAME: (we agree on this)

1080p30: 1965
1080p24: 1965
720p   : 1965
480p   : 1965

5X:
1080p30: 1195
1080p24: 1195
720p60 : 1195
480p   : 1195

3x:      (here's where our results are drastically different)
1080p30: 1195
1080p24: 1298
1080p25: 1195

BTW, you don't need to check recording vs. not recording because there is nothing in current fps implementation to support that, besides if timer B can go lower when recording vs. standby it's not going to do you any good because you would normally set it in standby, and if it goes lower in standby vs. recording the worst thing that happens is your recording stops.

so to sum things up, the goal is to choose values that give the maximum range of FPS, then pull them back a bit to some meaningful value on the safe side. i chose 650 since that allows me to overcrank up to 45fps (in my testing I can record 44fps reliably)

So I have mine set like:
#define FPS_TIMER_B_MIN (fps_timer_b_orig - (ZOOM ? 290 : MV720 ? 57 : MV1080CROP ? 650 : 57))

If we can agree that these values are safe, I will modify the pull request, if not, then I guess we'll have to go with the ones you reported initially.

We should be able to agree on this and the fact that it is safe to record up to 45fps in crop mode on the M according to my previous test results.

Quote from: dpjpandone on August 22, 2015, 05:11:00 AM
When you are testing the 3x crop mode, start with desired fps set to 45, and then start lowering timer b from there (it will save you lots of time and put timer a at a realistic value)

3x crop mode is "Movie crop mode" in the ML menu?

Quote from: dpjpandone on August 22, 2015, 05:11:00 AM
5X:
1080p30: 1195
....

3x:      (here's where our results are drastically different)
1080p30: 1195
...

You keep talking about this, is this "Zoom mode 3x/5x" for photos in standby? Why bother with it since I can't use it when switching to video anyway?

QuoteIf you want to try to record 44fps in 1080p crop mode, you have to set the compression method to ALL-I under "video hacks", just don't forget to set it back to IPP before you turn video hacks back off

This is the first time that I see this advice, Why wasn't this specified before daammit!!?!?
Yes it works, 1080@30 can be pushed up to 46.056fps so yeah limiting it at 45fps is nice.

/LE:
Using your build ( I presume you set  #define FPS_TIMER_B_MIN MIN(fps_timer_b_orig, 500) in it, right? ), you say "see how low you can push timer b before you have problems", so I set 1080@24 in Canon menu, crop mode ON, video hacks ALL-I, turn fps override on, push it to 34, "low jello 180d", actual fps 33.528 and this yields timer A at 532 and timer B at 1794.

But, I can't lower them, they're stuck at 532/1794 and in goes to 1794 (FT-X) where X is a growing value, I can go to FT-400 but I'm not sure that is what it should do.

Quote from: Licaon_Kter on August 23, 2015, 03:14:48 PM
3x crop mode is "Movie crop mode" in the ML menu?
You keep talking about this, is this "Zoom mode 3x/5x" for photos in standby? Why bother with it since I can't use it when switching to video anyway?
This is the first time that I see this advice, Why wasn't this specified before daammit!!?!?
Yes it works, 1080@30 can be pushed up to 46.056fps so yeah limiting it at 45fps is nice.

Movie crop mode is limited to 1792 pixels wide, and works with raw or h.264. 5X allows higher resolutions, but the preview is not framed accurately. It can oly be used with raw. So that is why we want a timer_b_min value for 5x, in case someone wants to use fps override with 5x raw video.

So we agree on the values I posted? I will update the pull request and add you and deafeyejedi as reviewers. If you can look at the pull request and click "approve" that would be helpful

https://bitbucket.org/hudson/magic-lantern/pull-requests/649/fps_timer_a_min-and-fps_timer_b_min-fixed/diff

Approved via Bitbucket!

QuoteMovie crop mode is limited to 1792 pixels wide, and works with raw or h.264. 5X allows higher resolutions, but the preview is not framed accurately. It can oly be used with raw. So that is why we want a timer_b_min value for 5x, in case someone wants to use fps override with 5x raw video.

You're using this term "movie crop mode" to refer to regular video mode, but most people use "crop mode" to mean video shot with the 3x/5x zoom. This could be confusing.

Quote from: Frank7D on August 23, 2015, 06:04:37 PM
You're using this term "movie crop mode" to refer to regular video mode, but most people use "crop mode" to mean video shot with the 3x/5x zoom. This could be confusing.

exactly

After you mentioned RAW it clicked for me, THERE the crop(?)/zoom(?) factor 3x/5x etc is mentioned. I can use "Movie crop" and set a lower resolution in RAW, and that yields 3x/5x/7x and I can go to 45 fps ( only at 960x480 or so on my M, given the card speed, but hey it's freaking RAW :) )

So maybe rephrase the whole idea again maintioning RAW or H.264 please? Because I'm rather lost here.

Perhaps it works for both h264 & MLV/RAW? [emoji6]

"movie crop mode" is a feature aavailable only on t3i and eosm. It works for both raw and h.264, the great thing about eosm is that movie crop mode is 1:1 pixels (no line skipping) just like other cams, but the preview is full color and framed correctly (unlike other cams that either frame in 5x, or greyscale)

https://vimeo.com/136241348

https://vimeo.com/136241300

@dpjpandone: i know what crop mode is, but you speak of 3x and 5x and I did not understand what mode is that, where 3x/5x CANON ZOOM PHOTO MODE STANDBY (as in my table) is one thing and 3X/5X MAGICLANTERN RAW VIDEO RECORDING is a whole different thing.

Yes I will mixed them up if you don't specify what you mean... BTW should I wonder what you think the values in my table above mean? Here's a hint: it's never RAW

Also, the table above needed 2 full battery charges, a lot of time, a way to note results, and a whole lot of will, and now you're telling me that The Method was kinda faulty... ;(

@dpjpandone: Using your build: https://bitbucket.org/hudson/magic-lantern/issues/2360/15-360-extra-pixels-of-noise-added-in-crop

So what are the steps to get 45fps crop mode video working? Both 1920x1080 H.264 and 960x480 raw?

Every time I go that high the screen flickers and so does the mov file. This is the first time I tried dpjpandone's build (https://www.dropbox.com/s/3d6zpxnndvhxpoa/magiclantern-Nightly.2015Aug21.EOSM202.zip). Up until now I was just testing what was in the pull request. That one works fine but it will only get to about 31fps max.

I take it that "Video Hacks" (soon to be called "Compression Method"?) is not ready for a pull request yet?

Well it's not perfect.


1080@30
fps override 45
low jello 180
crop on
raw 960x540
globaldraw off
info debug

also got the shutter to 180degrees

it yields >1000 frames since the card can't keep up
lowering the res a bit you can get it to work forever

Got it -- mlv or old school raw video?

I'm on location for a few days so I'll try it when I get home.

MLV_REC


I for one did not bother with the old format, was there any imediate thing that old format did better though?

Quote from: Licaon_Kter on September 02, 2015, 09:13:34 PM
was there any imediate thing that old format did better though?

I think it used to be that raw_rec was more stable but MLV version 2.0 (http://www.magiclantern.fm/forum/index.php?topic=7122.0) is definitely better.