L
Lightgreen
Guest
That's how it worked in former 4k implementation, literally with MJPEG being a motion JPEG codec, where both were done "on-DIGIC"
It is; that many frames per second in just JPEG, forget h264, is messy.
What's obviously happened like our cellphone maker counterparts, is with the advent of h264 4k in the M50, at 25fps at that, that's too much heat to brute force on DIGIC; they've obviously adopted a licensed h264 transcoder chip like everyone else and bit the bullet. Now heat is only an issue on sensor readout, not CPU-side, which limiting to a 1.6x crop does help as that's alot of data you're still pulling off the sensor at 25FPS. Cropping it, puts you on a similar playing field to a smaller sensor that's doing 4k, like say a Sony RX100.
DPAF works in 1080, and in stills, this is a DPAF sensor, still.
Firing just one side and not the other, is not buying you anything here.
The way DPAF works is the right and left cells fire concurrently during capture, thus it's a 24MP readout, but really twice as many pixels actually exist then necessary to produce that 24MP readout, hence the 5DSR has that pixel shift option on RAWs.
Mind you, the 1DX II, and 5DIV can already do DPAF + 4k, on a much older DIGIC, that is already brute forcing and doing DPAF calculations at the same time. I don't buy it.
I know what you're saying, but you're smart enough to know what I'm saying too, I gather.
You're saying heat is still an issue, I'm saying, with h264 support, they've moved away from brute force, which is a 10x drop in cpu "cost". Now the sensor, whole different ball game, hence the crop makes some sense.
Last edited:
