Adjustments to raw buffer height and skip values for EOSM/100D/700D/650D. This should resolve the "hiccup" issue on the 100D in zoom mode, the no compression corrupt video on the 100D in Movie Crop Mode and restore the full 1080 height in zoom mode for the EOSM/650D/700D cameras.
Your commit also let´s 1080 become 1082 every other time while scrolling for bigger aspect ratios.
Heh, the hiccup issue was fixed by (*height)-- and now the PR has (*height)++ or it's omitted; that's why you've got negative results.
My comment from the source (that some cameras need to add 1 etc) was based on this post (actually this file) - I was trying to match the EDMAC values (previously hardcoded). Turns out, the EDMAC values from Canon code were wrong (except for 5D3, where they were correctly adjusted in Canon code - see this issue I had when enabling 8..12-bit lossless).
Maybe all DIGIC 5 need (*height)--, and Canon engineers had similar problems? (which would explain the inconsistency in EDMAC configurations on various models).
Skip offsets do not affect the capture process (including hiccups) in any way - these are how our code interprets Canon's raw data, that's all.
The offsets affecting your focus maps may indicate another problem - centering the maps (which should be done with CropPosX/Y) probably doesn't work well. Torture test: does the focus pixel fix work with digital dolly enabled, on both directions?
Looks like I should have waited for 100D test results before putting up this pull request. There was a similar issue on the EOSM which was fixed by adjusting skip_top -- I assumed it would also work on the 100D hiccup issue.
I tested digital dolly on the focus pixels a while back. Looks like it might be time to revisit it along with CropPosX/Y. Focus pixels have become a moving target in the crop_rec_4k branch.
@danne - The EOSM and 700D also shows image sizes up to 1082 in zoom. I put back the (*height)-- that worked so well. Let's see if this combined with the skip_top change to zoom mode gives an image height of 1080 while resolving the "hiccup" issue.
Actually, this seems to work. Tested lossless modes with 5x zoom on my 100D and no issues. Didn´t do longer takes but the issue was pretty persistent on all files before.
Now I'm curious - did the (intermittent) hiccup issue appear on 650D/700D/M with (*height)++ ?
I never got the 700D to hiccup. There was an intermittent issue on the EOSM that was resolved by changing the skip_top setting so it wasn't related to the 100D hiccup.
There are no intermittent issues that could be solved by changing skip_top, that I can imagine; this simply declares how many pixels should be ignored from the top side (after the full image is already in main memory).
On the other hand, the dimensions from *width and *height are important, because they should match the dimensions of the captured image (whatever Canon code - or maybe crop_rec - has configured for current video mode) and they are used to configure the hardware to transfer the image into the main memory. That's why decreasing *height helped with the hiccups.
On 5D3, if you don't decrease *height, in 8...12-bit mode you'll get valid image only every other frame. If you decrease it too much, you still get valid image. I guess there's some undefined behavior (or just mysterious for us) if the EDMAC image size (in raw_lv_vsync) is larger than what the sensor is configured to provide (from 0xC0F06800/4).
Whatever caused that intermittent issue on the EOSM, I can no longer reproduce it.
I also committed the FPS_TIMER_A_MIN for the EOSM and it looks good over here.
Found a video of the intermittent issue on the EOSM in zoom mode. Did this late at night so it looks like a UFO! This came up when I increased the raw buffer height by 1 pixel and went away when skip_top was adjusted by 2 pixels. Can't reproduce it now so maybe it was just one of those weird inconsistent issues.
That's certainly not affected by the skip offsets; could be FPS override too high, something using high CPU usage and/or high amounts of memory bandwidth (there is a way to reproduce corrupted frames on 60D. It can be quite hard to reproduce (even some hundreds of good clips, and then a few bad frames all of a sudden, is not unlikely to happen).
Got a 650D user who PM'd me with his test results. Looks like these changes work fine on that camera too.