12 to 24 fps (FPS override Problem)

[dfort]

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

[Licaon_Kter]

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

[Licaon_Kter]

The defaults:

[a1ex]

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).

[Licaon_Kter]

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




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

[Licaon_Kter]

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

Now, how about unblocking the builds then.

[a1ex]

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

[dfort]

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.

[dfort]

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. 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        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. Am I looking in the right places to educate myself?

[Licaon_Kter]

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.

[dmilligan]

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

[dfort]

Thanks for the Hexspeak lesson 

[dpjpandone]

according to otheronepercent as of last december:

Code: [Select]

#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

[Licaon_Kter]

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


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


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

[Licaon_Kter]

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

[dpjpandone]

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

Code: [Select]

#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? 

[dpjpandone]

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.

[Licaon_Kter]

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

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

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.


10x

[dpjpandone]

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

[Licaon_Kter]

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?

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.

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? )

[dpjpandone]

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.

[dpjpandone]

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. 

[Licaon_Kter]

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...

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?

[dpjpandone]

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?

[Licaon_Kter]

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?