Cool. Good to know my firmware updates are good for something.
Yeah, looking forward to the holiday season, to... catch up with ML developments
Been a while since I worked on it and never noticed the comment about the 600D. Suppose it also applies to the 1100D?
From model_list.c in QEMU source:
{
.name = "600D",
.ram_size = 0x10000000, /* 256MB */
...
},
{
.name = "1100D",
.ram_size = 0x08000000, /* 128MB */
...
},
so the issue is much worse on 1100D.
However, out of all DIGIC 2 and newer models, the crown goes to 1000D (64 MB). Even the old 400D appears to have 128 MB.
Edit: apparently the sensor in 1100D might be faster than expected:
- 1100D might have 128 MPix/s (32 MHz x 4 channels, but default video readout apparently uses 2? I really need to double-check that)
That would be just as fast as 700D & co., if this hypothesis is valid. That is, faster than 600D & co.
Photo mode readout configuration: timer A = 1474, B = 2876, clock = 32 MHz => 7.55 fps at full resolution.
The camera is advertised for 3 frames per second, right? There are 4 pixels read out for each timer A increment, i.e. 4 channels read out at once. There is some overhead too, that's why timer A * 4 is greater than horizontal resolution.
Video readout configuration, from raw_res.txt:
720p25: A = 1000, B = 1280, readout size 1496 x 967 (this includes black borders)
720p30: A = 960, B = 1112, same readout size
Timer A can be pushed to 872 in both modes.
What's interesting: for each timer A increment, only 2 pixels appear to be read out. In other words, the sensor might throttled in LiveView. No other DIGIC <= 5 camera does that, to my knowledge, so I'd like to find out how it works. Will prepare some low-level tests.
Edit Jan 1: false alarm. The 1100D definitely uses 4 channels for LiveView readout. Daniel Rozsnyo took one of these apart and showed me the analog signal from one of these 4 channels in LiveView:
Reducing that overhead might be doable (likely one of the ADTG registers); doing so might enable higher frame rates, up to about some
theoretical 80 FPS at 1428x804 (i.e. full-width 16:9) !!!
1100D, on the other hand, is an interesting beast:
It runs at 32 MHz x 4 channels (i.e. pixel clock is the same 700D & co.), but for some reason, it has a huge overhead. In regular (24/25/30p) movie mode, C0F06084/88 is set to 0x200c3/0x3c903af, i.e. xmax = 1886 (likely rounded to 1888), out of which 390 pixels are cropped from the left side. ML still has to crop 68 pixels of left OB; that gives 1428 active horizontal pixels, 458 (!) for OB width and 2 pixels for rounding (guess); these require "only" 14.75 μs/line. The unexplained overhead would be 12.5 μs/line, or exactly 400 clock ticks. This one is worth fine-tuning, if you ask me.
Why?
- 720p24/30: 960 / 32 = 30 μs/line
- 720p25: 1000 / 32 = 31.25 μs/line
- FPS override: 872 / 32 = 27.25 μs/line
- theoretical value: (872 - 400) / 32 = 14.75 μs/line! (without altering OB areas)
For a 16:9 frame, which would be just 1428x804, it would require only 11.86 ms!
Assuming one can somehow drop 400 pixels from the left OB, that would free another 100 clock ticks, i.e. 11.63 μs/line, or 9.35 ms for a 16:9 LiveView frame.
